Information management system and method

ABSTRACT

An information management system includes a computer server. The computer server includes an interface module. The information management system also includes a plurality of card processors in communication with the computer server via the interface module. The computer server is configured to interface with each of the plurality of card processors via the interface module. The computer server is configured to choose one of the plurality of card processors in accordance with a unique identifier associated with a card product to process information associated with the card product.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a U.S. National Phase patent application that claimsthe benefit under 35 U.S.C. § 365 of International Application No.PCT/US2006/011148, filed Mar. 24, 2006, the entire contents of which arehereby incorporated by reference herein.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the U.S. Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND

1. Field of the Invention

The present invention relates to computer-based information managementsystems. More particularly, the present invention relates to a systemand method for managing information associated with card products.

2. Background Information

Increasing numbers of retail and other institutions are now offeringcash-equivalent value in the form of gift cards. The gift card industryhas experienced substantial growth over the past few years. Total giftcard sales reached approximately $20 billion in 2004. The range of giftcards offered by institutions has become expansive, including cards fromretailers, supermarkets, drug-stores, gas stations, restaurants,convenience stores, and hair salons, to name but a few.

Most gift cards are associated with a particular retailer or merchant.In other words, any value stored on the gift card can only be used topurchases goods and services at the particular retailer or merchant fromwhom the gift card was purchased, so that the merchant can gain thebenefit of a guaranteed sale. Such proprietary gift cards can bereferred to as “closed system” cards. Merchants can cover the cost oftheir gift card programs from the margin in their products, which canbe, for example, $15 or more on a $50 sale.

However, a growing industry trend is for financial institutions to offerprepaid or “open system” branded gift cards. Open system cards areissued by a federally-regulated financial institution and carry a majornetwork brand, such as, for example, MasterCard™, VISA™, Discover™ andthe like, and including debit networks such as STAR™, Pulse™, NYCE™ andothers. For example, the prepaid VISA™ gift card can be used at anyretailer or merchant that accepts VISA™ debit cards, which includesmillions of locations worldwide, as well as Internet and mailorder/telephone order merchants. Such prepaid gift cards can be used forcorporate incentives, rebates and promotions, and can be sold inbranches of a financial institution, through the financial institution'sconsumer website, or distributed through corporate clients. The marketfor bank-issued gift cards is predicted to grow from $3 billion in 2003to approximately $31 billion in 2007.

Open system branded gift cards differ from proprietary “store” giftcards in several aspects. For example, bank-issued gift cards can beused at any merchant. Except for a small amount of interchange, the bankor other financial institution does not benefit from the sale of theproducts/services purchased with the card or share in the profits of thesale. Rather, monthly administrative fees can be used to maintain theeconomic viability of the bank-issued gift card product.

Open system branded gift cards share many basic features. For example,these cards are guaranteed by the network and financial institution.Funds are maintained and controlled by the financial institution. Cardscan be used anywhere the network brands are accepted. Cards can bereplaced if lost, stolen or expired. In addition, consumers can gainprotection from fraudulent activity.

However, conventional methods of purchasing such gift cards has beenrelatively complex. For example, consumers can wait for long periods oftime at a point of sale while the clerk or sales agent processes thegift card purchase. Online gift card purchasing sites do little toalleviate the complexity of purchasing gift cards. For example, manyonline websites experience difficulty in assigning users, presentmultiple, complex screens through which users must navigate to purchasegift cards, and other like difficulties.

Additionally, because each of these gift cards is associated with aparticular financial institution, consumers are forced to interact withmany different entities to purchase and manage these gift cards. Forexample, if a consumer or other user possesses several gift cards, eachissued by a different financial institution, the user must navigate toand access a different website for each gift card from each financialinstitution to sign up and administer each card separately.

Therefore, there is a need for a system that can reduce the complexityand streamline the process of managing and administering gift cards andother non-reloadable and reloadable card products across many financialinstitutions.

SUMMARY OF THE INVENTION

A system for managing information associated with card products and amethod for managing card product information across multiple cardprocessors are disclosed. In accordance with exemplary embodiments ofthe present invention, according to a first aspect of the presentinvention, an information management system includes a computer server.The computer server includes an interface module. The informationmanagement system includes a plurality of card processors incommunication with the computer server via the interface module. Thecomputer server is configured to interface with each of the plurality ofcard processors via the interface module. The computer server isconfigured to choose one of the plurality of card processors inaccordance with a unique identifier associated with a card product toprocess information associated with the card product.

According to the first aspect, the interface module can be configured totransform messages for communication to a respective card processor intoa format utilized by the respective card processor. Messages to the cardprocessors can include a query comprising a computer network address ofa file. An encryption of the computer network address can be appended toan end of the query. The interface module can be configured to detecttampering with the computer network address by comparing the computernetwork address and a decryption of the encrypted computer networkaddress. Alternatively, the interface module can be configured to detecttampering with the computer network address by comparing the encryptedcomputer network address and a re-encryption of the computer networkaddress. The interface module can be configured to receive informationassociated with card products from each of the card processors. Theinformation from each of the card processors can be normalized totransform the information into a uniform format utilized by the computerserver. The transformed information can be validated to ensure accuracyof the information.

According to the first aspect, the information management system caninclude database in communication with the computer server. The databasemodule can be configured to store information associated with cardproducts. The information management system can include a managementmodule in communication with the database. The management module can beconfigured to manage the information management system. The cardprocessors can be configured to associate corresponding bankidentification numbers (BINs) to the card products. The computer servercan be configured to allocate card numbers corresponding to each BIN forthe card products. The computer server can be configured to display asummary of card numbers for each BIN through the graphical userinterface. Each card product can comprise a card number. The card numbercan comprise a first portion of digits and a second portion of digits.The first portion of digits can comprise a BIN. The card processors canbe configured to associate BINs to the card products. The computerserver can be configured to allocate card numbers to substantially allof the second portion of digits for each BIN.

According to a second aspect of the present invention, a card productmanagement system includes an agent portal module. The card productmanagement system includes a plurality of card processors incommunication with the agent portal module. The agent portal module isconfigured to interface with each of the plurality of card processors.The agent portal module is configured to choose one of the plurality ofcard processors in accordance with a unique identifier associated with acard product to process information associated with the card product.

According to the second aspect, the agent portal module can beconfigured to manage information associated with card products for theplurality of card processors. The agent portal module can include aclient application server module. The client application server modulecan be configured to transform messages for communication to arespective card processor into a format utilized by the respective cardprocessor. Messages to the card processors can include a querycomprising a computer network address of a file. An encryption of thecomputer network address can be appended to an end of the query. Theclient application server module can be configured to detect tamperingwith the computer network address by comparing the computer networkaddress and a decryption of the encrypted computer network address.Alternatively, the client application server module can be configured todetect tampering with the computer network address by comparing theencrypted computer network address and a re-encryption of the computernetwork address. For example, the encryption of the computer networkaddress can comprise a cryptographic hash function. The clientapplication server module can be configured to receive informationassociated with card products from each of the card processors. Theinformation from each of the card processors can be normalized totransform the information into a uniform format utilized by the agentportal module. The information from each card processor can comprise aplurality of reports. The plurality of reports can comprise at least oneof a general report, a posted report and an authorization report. Thetransformed information can be validated to ensure accuracy of theinformation.

According to the second aspect, the client application server module canbe configured to generate reports for information associated with cardproducts. Each report can be populated with information in accordancewith an identification of a user. The card product management system cancomprises a database module in communication with the client applicationserver module. The database module can be configured to storeinformation associated with card products. The card product managementsystem can include a management application server module incommunication with the database module. The management applicationserver module can be configured to manage the card product managementsystem. The agent portal module can be configured to allow access byusers to manage information associated with the card products. The agentportal module can include a graphical user interface module. Thegraphical user interface module can be configured to display a graphicaluser interface through which users interact with the card productmanagement system.

According to the second aspect, a user can be granted access to the cardproduct management system through the graphical user interface using apassword and an associated computer network address of the user.Products can be presented to a user through the graphical user interfacein accordance with at least one of a user identification and anassociation with a financial institution. A theme of the graphical userinterface can be associated with each card processor. Each cardprocessor can be presented with the theme associated with the cardprocessor when interacting with the card product management systemthrough the graphical user interface. The card processors can beconfigured to associate corresponding BINs to the card products. Theagent portal module can be configured to allocate card numberscorresponding to each BIN for the card products. The agent portal modulecan be configured to display a summary of card numbers for each BINthrough the graphical user interface.

According to the second aspect, the unique identifier can comprise abank identification number (BIN). Each card product can comprise a cardproduct number. The card product number can comprise a first portion ofdigits and a second portion of digits. The first portion of digits cancomprise a BIN. The card processors can be configured to associate BINsto the card products. The agent portal module can be configured toallocate card numbers to substantially all of the second portion ofdigits for each BIN. The card product can comprise a gift card. The giftcard can be issued by a financial institution. The card product cancomprise a debit card. The card product can comprise a health savingsaccount (HSA) card. The card product can comprise a flexible spendingaccount (FSA) card. The card product can comprise a reloadable payrollcard. At least one of the plurality of card processors can comprise abank or the like.

According to a third aspect of the present invention, a system forprocessing card products includes a plurality of card products. Eachcard product comprises a card product number. The card product numbercomprises a first portion of digits and a second portion of digits. Thefirst portion of digits comprises a bank identification number (BIN).Each BIN is assigned to a card processor. The system includes anon-processor. The non-processor is configured to manage informationassociated with the plurality of card products. The non-processor isconfigured to assign values to substantially all of the second portionof digits of each card product.

According to the third aspect, the values assigned to substantially allof the second portion of digits of each card product can comprise a cardnumber. The non-processor can be configured to allocate card numbers foreach BIN. Card numbers can be allocated sequentially for each BIN.Alternatively, card numbers can be allocated randomly for each BIN. Thevalues assigned to substantially all of the second portion of digits ofeach card product can correspond to separate users.

According to a fourth aspect of the present invention, a method ofmanaging card product information includes the steps of: a.) interfacingwith each of a plurality of card processors; and b.) selecting one ofthe plurality of card processors in accordance with a unique identifierassociated with a card product to process information associated withthe card product.

According to the fourth aspect, the method can include the steps of: c.)managing information associated with card products for the plurality ofcard processors; and d.) transforming messages for communication to arespective card processor into a format utilized by the respective cardprocessor. Messages to the card processors can include a querycomprising a computer network address of a file. The method can includethe steps of: e.) encrypting the computer network address; f.) appendingthe encrypted computer network address to an end of the query; and g.)detecting tampering with the computer network address by comparing thecomputer network address and a decryption of the encrypted computernetwork address. Alternatively, step (g) can comprise the step of: g.)detecting tampering with the computer network address by comparing theencrypted computer network address and a re-encryption of the computernetwork address. For example, according to an exemplary embodiment ofthe fourth aspect, step (e) can be performed using a cryptographic hashfunction. The method can include the steps of: h.) receiving informationassociated with card products from each of the card processors; and i.)normalizing the information from each of the card processors totransform the information into a uniform format. The information fromeach card processor can comprise a plurality of reports. The pluralityof reports can comprise at least one of a general report, a postedreport and an authorization report.

According to the fourth aspect, the method can include the steps of: j.)validating the transformed information to ensure accuracy of theinformation; k.) generating reports for information associated with thecard product; l.) populating each report with information in accordancewith an identification of a user; m.) storing information associatedwith card products; and n.) providing access to users to manageinformation associated with card products; o.) displaying a graphicaluser interface through which users access information associated withcard products; p.) granting access to a user through the graphical userinterface using a password and an associated computer network address ofthe user; and q.) presenting products to a user through the graphicaluser interface in accordance with at least one of a user identificationand an association with a financial institution. A theme of thegraphical user interface can be associated with each card processor. Themethod can include the step of: r.) presenting each card processor withthe theme associated with the card processor when interacting throughthe graphical user interface. The card processors can be configured toassociate corresponding bank identification numbers (BINs) to the cardproducts. The method can include the step of: s.) allocating cardnumbers corresponding to each BIN for the card products. According tothe fourth aspect, the method can include the step of: t.) displaying asummary of card numbers for each BIN.

According to the fourth aspect, the unique identifier can comprise abank identification number (BIN). Each card product can comprise a cardproduct number. The card product number can comprise a first portion ofdigits and a second portion of digits. The first portion of digits cancomprise a BIN. The card processors can be configured to associate BINsto the card products. The method can include the step of: v.) allocatingcard numbers to substantially all of the second portion of digits foreach BIN. The card product can comprise a gift card. The gift card canbe issued by a financial institution. The card product can comprise adebit card. The card product can comprise a health savings account (HSA)card. The card product can comprise a flexible spending account (FSA)card. The card product can comprise a reloadable payroll card. At leastone of the plurality of card processors comprises a bank.

According to a fifth aspect of the present invention, a method ofprocessing card products includes the steps of: a.) associating a bankidentification number (BIN) to each of a plurality of card products by acard processor, wherein each card product comprises a card productnumber, wherein the card product number comprises a first portion ofdigits and a second portion of digits, and wherein the first portion ofdigits comprises the BIN; and b.) assigning values to substantially allof the second portion of digits of each card product by a non-processor,wherein the non-processor is configured to manage information associatedwith the plurality of card products.

According to the fifth aspect, the values assigned to substantially allof the second portion of digits of each card product can comprise a cardnumber. The method can include the step of: c.) allocating card numbersfor each BIN by the non-processor. Step (c) can comprise the step of:d.) sequentially allocating card numbers for each BIN. Alternatively,step (c) can comprise the step of: e.) randomly allocating card numbersfor each BIN. The values assigned to substantially all of the secondportion of digits of each card product can correspond to separate users.

According to a sixth aspect of the present invention, a system formanaging card product information includes means for interfacing witheach of a plurality of card processors. The system includes means forselecting one of the plurality of card processors in accordance with aunique identifier associated with a card product to process informationassociated with the card product.

According to the sixth aspect, the system can include means for managinginformation associated with card products for the plurality of cardprocessors. The system can include means for transforming messages forcommunication to a respective card processor into a format utilized bythe respective card processor. Messages to the card processors include aquery comprising a computer network address of a file. The system caninclude means for encrypting the computer network address. The systemcan include means for appending the encrypted computer network addressto an end of the query. The system can include means for detectingtampering with the computer network address by comparing the computernetwork address and a decryption of the encrypted computer networkaddress. Alternatively, the system can include means for detectingtampering with the computer network address by comparing the encryptedcomputer network address and a re-encryption of the computer networkaddress. For example, the encrypting means can use a cryptographic hashfunction to encrypt the computer network address.

According to the sixth aspect, the system can include means forreceiving information associated with card products from each of thecard processors. The system can include means for normalizing theinformation from each of the card processors to transform theinformation into a uniform format. The information from each cardprocessor can comprise a plurality of reports. The plurality of reportscan comprise at least one of a general report, a posted report and anauthorization report. The system can include means for validating thetransformed information to ensure accuracy of the information. Thesystem can include means for generating reports for informationassociated with the card product. The system can include means forpopulating each report with information in accordance with anidentification of a user. The system can include means for storinginformation associated with card products. The system can include meansfor providing access to users to manage information associated with cardproducts. The system can include means for displaying a graphical userinterface through which users access information associated with cardproducts.

According to the sixth aspect, the system can include means for grantingaccess to a user through the graphical user interface using a passwordand an associated computer network address of the user. The system caninclude means for presenting products to a user through the graphicaluser interface in accordance with at least one of a user identificationand an association with a financial institution. A theme of thegraphical user interface is associated with each card processor. Thesystem can include means for presenting each card processor with thetheme associated with the card processor when interacting through thegraphical user interface. The card processors can be configured toassociate corresponding bank identification numbers (BINs) to the cardproducts. The system can include means for allocating card numberscorresponding to each BIN for the card products. The system can includemeans for displaying a summary of card numbers for each BIN.

According to the sixth aspect, the unique identifier can comprise a bankidentification number (BIN). Each card product can comprise a cardproduct number. The card product number can comprise a first portion ofdigits and a second portion of digits. The first portion of digits cancomprise a BIN. The card processors can be configured to associate BINsto the card products. The system can include means for allocating cardnumbers to substantially all of the second portion of digits for eachBIN. The card product can comprise a gift card. The gift card can beissued by a financial institution. The card product can comprise a debitcard. The card product can comprise a health savings account (HSA) card.The card product can comprise a flexible spending account (FSA) card.The card product can comprise a reloadable payroll card. At least one ofthe plurality of card processors comprises a bank.

According to a seventh aspect of the present invention, a system forprocessing card products includes means for associating a bankidentification number (BIN) to each of a plurality of card products by acard processor. Each card product comprises a card product number. Thecard product number comprises a first portion of digits and a secondportion of digits. The first portion of digits comprises the BIN. Thesystem includes means for assigning values to substantially all of thesecond portion of digits of each card product by a non-processor. Thenon-processor is configured to manage information associated with theplurality of card products.

According to the seventh aspect, the values assigned to substantiallyall of the second portion of digits of each card product can comprise acard number. The system can include means for allocating card numbersfor each BIN by the non-processor. The system can include means forsequentially allocating card numbers for each BIN. Alternatively, thesystem can include means for randomly allocating card numbers for eachBIN. The values assigned to substantially all of the second portion ofdigits of each card product can correspond to separate users.

According to a eighth aspect of the present invention, acomputer-readable medium contains a computer program for managing cardproduct information. The computer program performs the steps of: a.)interfacing with each of a plurality of card processors; and b.)selecting one of the plurality of card processors in accordance with aunique identifier associated with a card product to process informationassociated with the card product.

According to the eighth aspect, the computer program can perform thesteps of: c.) managing information associated with card products for theplurality of card processors; and d.) transforming messages forcommunication to a respective card processor into a format utilized bythe respective card processor. Messages to the card processors caninclude a query comprising a computer network address of a file. Thecomputer program can perform the steps of: e.) encrypting the computernetwork address; f.) appending the encrypted computer network address toan end of the query; and g.) detecting tampering with the computernetwork address by comparing the computer network address and adecryption of the encrypted computer network address. Alternatively, forstep (g), the computer program can perform the step of: g.) detectingtampering with the computer network address by comparing the encryptedcomputer network address and a re-encryption of the computer networkaddress. For example, step (e) can be performed by the computer programusing a cryptographic hash function. The computer program can performthe steps of: h.) receiving information associated with card productsfrom each of the card processors; and i.) normalizing the informationfrom each of the card processors to transform the information into auniform format. The information from each card processor can comprise aplurality of reports. The plurality of reports can comprise at least oneof a general report, a posted report and an authorization report.

According to the eighth aspect, the computer program can perform thesteps of: j.) validating the transformed information to ensure accuracyof the information; k.) generating reports for information associatedwith the card product; l.) populating each report with information inaccordance with an identification of a user; m.) storing informationassociated with card products; n.) providing access to users to manageinformation associated with card products; o.) generating a graphicaluser interface through which users access information associated withcard products; p.) granting access to a user through the graphical userinterface using a password and an associated computer network address ofthe user; and q.) generating a presentation of products to a userthrough the graphical user interface in accordance with at least one ofa user identification and an association with a financial institution. Atheme of the graphical user interface can be associated with each cardprocessor. The computer program can perform the step of: r.) generatingthe theme associated with the card processor to each card processor wheninteracting through the graphical user interface. The card processorscan be configured to associate corresponding bank identification numbers(BINs) to the card products. The computer program can perform the stepsof: s.) allocating card numbers corresponding to each BIN for the cardproducts; and t.) generating a summary of card numbers for each BIN.

According to the eighth aspect, the unique identifier can comprise abank identification number (BIN). Each card product can comprise a cardproduct number. The card product number can comprise a first portion ofdigits and a second portion of digits. The first portion of digits cancomprise a BIN. The card processors can be configured to associate BINsto the card products. The computer program can perform the step of: v.)allocating card numbers to substantially all of the second portion ofdigits for each BIN. The card product can comprise a gift card. The giftcard can be issued by a financial institution. The card product cancomprise a debit card. The card product can comprise a health savingsaccount (HSA) card. The card product can comprise a flexible spendingaccount (FSA) card. The card product can comprise a reloadable payrollcard. At least one of the plurality of card processors comprises a bank.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the present invention will becomeapparent to those skilled in the art upon reading the following detaileddescription of preferred embodiments, in conjunction with theaccompanying drawings, wherein like reference numerals have been used todesignate like elements, and wherein:

FIG. 1 is a diagram illustrating a card product management system, inaccordance with an exemplary embodiment of the present invention.

FIG. 2 is report specification for a general or non-financial report, inaccordance with an exemplary embodiment of the present invention.

FIG. 3 is report specification for a posted report, in accordance withan exemplary embodiment of the present invention.

FIG. 4 is report specification for an authorization report, inaccordance with an exemplary embodiment of the present invention.

FIG. 5 is an example of a graphical user interface for viewing ordersthrough the card product management system, in accordance with anexemplary embodiment of the present invention.

FIG. 6 is a diagram illustrating a transaction flow for a gift cardissued by a card processor, in accordance with an exemplary embodimentof the present invention.

FIG. 7 is an illustration of an overview page for the managementapplication server module, in accordance with an exemplary embodiment ofthe present invention.

FIGS. 8A, 8B and 8C illustrate a processors page, a clients page and aprograms page, respectively, in accordance with an exemplary embodimentof the present invention.

FIG. 9 illustrates a client detail page, in accordance with an exemplaryembodiment of the present invention.

FIG. 10 illustrates a program details page, in accordance with anexemplary embodiment of the present invention.

FIG. 11 illustrates a clients contracts page, in accordance with anexemplary embodiment of the present invention.

FIG. 12 illustrates a client quality page, in accordance with anexemplary embodiment of the present invention.

FIG. 13 illustrates a program project plans page, in accordance with anexemplary embodiment of the present invention.

FIG. 14 illustrates a program finding page, in accordance with anexemplary embodiment of the present invention.

FIG. 15 illustrates a program attributes page, in accordance with anexemplary embodiment of the present invention.

FIG. 16 illustrates a gift card report page, in accordance with anexemplary embodiment of the present invention.

FIG. 17 illustrates a work queue report page, in accordance with anexemplary embodiment of the present invention.

FIG. 18 illustrates a commission payable summary report page, inaccordance with an exemplary embodiment of the present invention.

FIG. 19 illustrates a report files page, in accordance with an exemplaryembodiment of the present invention.

FIG. 20 illustrates a financial report page, in accordance with anexemplary embodiment of the present invention.

FIG. 21 illustrates an account reconciliation report page, in accordancewith an exemplary embodiment of the present invention.

FIG. 22 illustrates a statement generated by the card product managementsystem, in accordance with an exemplary embodiment of the presentinvention.

FIG. 23 illustrates a statement definition report page, in accordancewith an exemplary embodiment of the present invention.

FIG. 24 illustrates an exception report page, in accordance with anexemplary embodiment of the present invention.

FIGS. 25A and 25B illustrate exception detail report pages, inaccordance with an exemplary embodiment of the present invention.

FIG. 26 illustrates a financial reports page, in accordance with anexemplary embodiment of the present invention.

FIGS. 27A and 27B illustrate financial report pages, in accordance withan exemplary embodiment of the present invention.

FIG. 28 illustrates a card number summary page, in accordance with anexemplary embodiment of the present invention.

FIG. 29 is a flowchart illustrating steps for managing card productinformation, in accordance with an exemplary embodiment of the presentinvention.

FIG. 30 is a flowchart illustrating steps for detecting tampering withinformation communicated to a card processor, in accordance with anexemplary embodiment of the present invention.

FIG. 31 is a flowchart illustrating steps for processing card products,in accordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Exemplary embodiments of the present invention are directed to a systemfor managing information associated with card products and a method formanaging card product information across multiple card processors.According to exemplary embodiments, a single bank agent portal providesan interface to multiple card processors to support administration andmanagement of cards or other card products issued by different entities,such as, for example, financial institutions (e.g., banks) and the like.The bank agent portal can then choose one of the card processors toprocess information associated with the card products using uniqueidentifying information associated with each card product. The cardproducts can include, for example, gift cards (e.g., bank-issued giftcards), debit cards, and other non-reloadable card products, as well asreloadable card products, such as, for example, health savings account(HSA) cards, flexible spending account (FSA) cards, reloadable payrollcards and the like. By providing a single interface to multiple cardprocessors, a user can effectively and easily manage any or all of thesecard products and other types of like financial transactions from asingle site, regardless of the entity that issued the card.

According to exemplary embodiments, the bank agent portal provides alayer of abstraction between the user and the card processors. In otherwords, the present invention handles any and all inconsistencies anddifferences in interfaces, communications, data formats and the likebetween the various card processors, so that the user need only interactwith a single, unified interface. Thus, the user can purchase, manage,and conduct administrative functions for any number of card productsfrom any number of financial institutions without the need to separatelyconduct business with each institution (e.g., through each financialinstitution's website). For example, the user can generate and viewsummary reports of financial information associated with the cardproducts issued from the different financial institutions.

According to an additional exemplary embodiment of the presentinvention, the card product management system can be used to allocatecard numbers to card products issued by the financial institutions. Eachcard product includes a card product number that uniquely identifies thecard, for example, a sixteen digit number or the like. For example, thefirst six digits of the card product number can be a bank identificationnumber (BIN) assigned by the financial institution to a card processor.For the illustration of bank-issued gift cards, the remaining (e.g.,ten) digits are conventionally used for assigning a BIN extension (e.g.,six digits), a card number (e.g., three digits), and a check bit (e.g.,one digit). The values of these remaining digits are also conventionallyassigned by the financial institution. However, according to theadditional exemplary embodiment, the card product management system canassign card numbers for the card products by using the entirety of theremaining digits (e.g., all ten remaining digits) to allocate cardnumbers for a particular BIN. An authorized user can then view, forexample, a distribution summary of available card numbers for each BIN.

These and other aspects of the present invention will now be describedin greater detail. FIG. 1 is a diagram illustrating a card productmanagement system 100, in accordance with an exemplary embodiment of thepresent invention. The card product management system 100 (also referredto herein as simply the “system 100”) includes an agent portal module105. A plurality of card processors 110 (card processor 1, cardprocessor 2, card processor 3, . . . , card processor N, wherein N canbe any suitable number) are in communication with the agent portalmodule 105. Each card processor 110 can communicate with the agentportal module 105 using any suitable form of communication medium andprotocol, such as, for example, a local or remote network connection(e.g., via an intranet or the Internet or the like), a direct connection(e.g., a cable, such as a RS-232 connection), or any other suitablewired or wireless direct or networked connection.

According to exemplary embodiments, the agent portal module 105 isconfigured to interface with each of the card processors 110. Each cardprocessor 110 can communicate with the agent portal module 105 in amanner that can be different than any or all of the other cardprocessors 110. In other words, each card processor 110 can communicatewith the agent portal module 105 using a different communicationtechnology, protocol, protocol package, medium and the like. Forpurposes of illustration and not limitation, the first and third cardprocessors 110 can use SOAP (the Simple Object Access Protocol) tocommunicate with the agent portal module 105, while the second and Nthcard processors 110 can use XML-RPC to communicate with the agent portalmodule 105, although any suitable communication protocol can be used bythe card processors 110. The agent portal module 105 is configured toencapsulate the interface to each card processor 110 so that the agentportal module 105 can communicate with each card processor 110 using thecommunication protocol used and understood by the respective cardprocessor 110. Continuing with the present illustration, to communicatewith the first and third card processors 110, the agent portal module105 would use SOAP, while XML-RPC would be used to communicate with thesecond and Nth card processors 110. The agent portal module 105 cansupport any suitable communication protocol. As additional cardprocessors 110 are placed in communication with the agent portal module105, the communication parameters (protocol, message format and thelike) for each new card processor 110 can be provided so that the agentportal module 105 can be configured to communicate with each new cardprocessor 110 in the manner designated.

As used herein, a “card processor” is any suitable entity that servicesor processes card products. As used herein, a “card issuer” is anysuitable entity that issues card products (e.g., an issuing bank orother like entity that is capable of issuing card products). Forexample, a card issuer assigns BINs to each card processor. As usedherein, a “card product” can be any suitable type of non-reloadable orreloadable card or card-based product, such as, for example, a giftcards (e.g., a bank-issued gift cards), debit cards, health savingsaccount (HSA) cards, flexible spending account (FSA) cards, reloadablepayroll cards, travel cards, professional or collegiate team cards,savings account cards, credit cards or the like. For example, in thebank-issued gift card industry, a card processor 110 is simply referredto as a “processor” or “card processor.” A processor performs suchfunctions as, for example, creating and maintaining cards and cardproduct information, connecting with payment networks and sales agentsto authorize card sales and purchase transactions, posting cardtransactions and fees to the appropriate card, providing card reportdata, and the like. Thus, as used herein, a “non-processor” refers to anentity other than a “processor” (i.e., other than an entity thatprocesses or services card products). For example, the agent portalmodule 105 can be considered a “non-processor.” However, those ofordinary skill in the art will recognize that the card processor 110 canbe any suitable entity that is capable of processing or servicing anysuitable type of card product. According to exemplary embodiments, thecard product management system 100 is configured to manage theinformation associated with the card products for the plurality of cardprocessors 110.

The agent portal module 105 is configured to choose one of the pluralityof card processors 110 in accordance with a unique identifier associatedwith a card product to process information associated with the cardproduct. According to exemplary embodiments, each card product has aunique identifier that allows the card product management system 100 toassociate a card product with the card processor 110 that generated thatcard product identifier. The unique identifier can be any suitablenumeric or alpha-numeric string of characters, icon(s), symbol(s),image(s) or the like that is capable of uniquely identifying a cardproduct and associating the card product with the card processor 110that generated the card product identifier. For purposes of illustrationand not limitation, assume that the card product is a bank-issued giftcard. Such gift cards can include a sixteen digit numeric string,generally of the form: XXXX XXXX XXXX XXXX, where “X” can be any digitfrom 0 to 9, inclusive. The first six digits can comprise a bankidentification number (BIN), i.e., a number that uniquely identifies thefinancial institution (e.g., bank) that services and/or processes thegift card, although any suitable number of digits can be used to specifythe BIN. BINs can be assigned to each card processor 110 by cardissuers, and the card processors 110 generally associate authorized BINsto the card products. The agent portal module 105 can then use the BINassociated with a card product to determine which of the plurality ofcard processors 110 with which to communicate information associatedwith the card product. Once the appropriate card processor 110 has beendetermined, the agent portal module 105 can then communicate with thecard processor 110 using the method of communication and protocol nativeto the card processor 110. It is again noted that the present example ismerely for purposes of illustration. Any suitable unique identifier canbe used for each card product, as some card-based products may not useBINs.

Those of ordinary skill will recognize that the agent portal module 105can be scaled to multiple agent portal modules 105 interconnected bysuitable computer network communications to handle any suitable numberof card processors 110.

The agent portal module 105 includes a client application server module115. According to an exemplary embodiment, the client application servermodule 105 is configured to handle the communication and message passingwith the card processors 110 on behalf of the agent portal module 105.The client application server module 105 is configured to choose thecard processor 110 with which to communicate information associated witha card product based on the unique identifier of the card product. Forexample, the client application server module 115 can maintain orotherwise store a look-up table that maps the unique identifiers withthe corresponding card processors 110. For purposes of illustration andnot limitation, assuming that the card products are bank-issued giftcards or the like, then the look-up table can include a mapping of BINsto banks, such that information associated with a card product can besent to the bank based on the BIN of the card product.

In addition, the client application server module 115 is configured totransform messages for communication to a respective card processor 110into the message format utilized by the respective card processor 110.As discussed previously, any or all of the card processors 110 can use adifferent communication protocol for passing messages, data and otherinformation. Once the client application server module 115 determineswhich of the card processors 110 to send the information, the clientapplication server module 115 can then format the message in anappropriate manner (e.g., pre-pending a header and appending a checksumand the like to the body of the message) to conform to the protocol usedby the selected card processor 110. For example, the client applicationserver module 115 can maintain a look-up table that associates cardprocessors 110 with communication protocols, so that for any particularcard processor 110, the client application server module 115 candetermine which communication protocol and other like parameters aresupported by the selected card processor 110. Once appropriatelyformatted, the client application server module 115 can transmit theformatted message to the card processor 110. By managing the details ofeach communication link with each card processor 110, rather than havingthe card processors 110 conform to a communication protocol establishedby the card product management system 100, additional card processors110 can be easily added or otherwise connected to the system 100 withlittle or no modification to the systems of the card processors 110.Alternatively, the card processor 110 can choose to communicate with theapplication server module 115 via a standard communication format andprotocol established by the card product management system 100.

The client application server module 115 is also configured to receiveinformation associated with card products from each of the cardprocessors 110. However, any or all of the card processors 110 can sendinformation (i.e., the data contained in the messages) in different dataformats or a standard format provided by the card product managementsystem 100. For example, numeric values of information can be specifiedusing varying decimal places or none at all, codes or responses for aparticular reply can be specified differently, and the like. Althoughthe client application server module 115 can maintain separate data anddata structures corresponding to each card processor 110, suchprocessing tends to increase the complexity of the system 100.

According to an exemplary embodiment, the client application servermodule 115 is configured to normalize or otherwise map the informationcontained in each message from each of the card processors 115 totransform the information into a uniform format utilized by the cardproduct management system 100. The client application server module 115can use any suitable data format for all or substantially all processingwithin the system 100. For example, the client application server module115 can maintain or otherwise store a suitable look-up or translationtable to normalize or otherwise convert the information from the formatsupported by the card processor 110 to the format supported by the cardproduct management system 100, and vice versa. For example, the clientapplication server module 115 can transform data such as, for example,status codes, responses/replies, transaction details, or any othersuitable information into the corresponding status codes,responses/replies, transaction details used by the client applicationserver module 115.

For purposes of illustration and not limitation, assume that the clientapplication server 115 receives a message from a particular cardprocessor 110 that includes two fields. The client application servermodule 115 uses a uniform data format in which the first field is a giftcard dollar amount, specified with two decimal places. The second fieldis an authorization field, specified as “ACCEPT” or “DENY.” However, theparticular card processor 110 specifies the two fields differently—thefirst field is specified in whole numbers (i.e., no decimals), and thesecond fields is either “OK” or “NOT OK.” Thus, the two fields arepopulated by the card processor 110 with, for example, the value “5000”and the response “OK.” The client application server module 115 candetermine the particular card processor 110 from which the message wasreceived (e.g., by using the unique identifier associated with the cardproduct to which the message pertains). The client application servermodule 115 can then perform a table look-up or translation to determinethat, for this particular card processor 110, the value in the firstfield (i.e., “5000”) must be divided by 100 to obtain a value with twodecimal points, and that the authorization response of “OK” correspondsto “ACCEPT.” Thus, by normalizing the data from each card processor 110into a uniform data format, the client application server module 115 canmanage any differences between data formats across the plurality of cardprocessors 110. In addition, by managing the details of the data formatsupported by each card processor 110, rather than having the cardprocessors 110 conform to the data format used by the card productmanagement system 100, additional card processors 110 can be easilyadded or otherwise connected to the system 100 with little or nomodification to the systems of the card processors 110.

Upon normalization into the format supported by the card productmanagement system 100, the client application server module 115 isconfigured to validate or otherwise verify the normalized data to ensurethe accuracy of that data. For example, since the client applicationserver module 115 “understands” the format the data is to be in, theclient application server module 115 can perform, for example, bounds orrange checking on data, data verification, and other suitable checks onthe normalized data. For example, continuing with the previousillustration, assume that the first field (i.e., the gift card dollaramount) is to be specified with two decimal places and contain a valuebetween $0.00 and $100.00. Therefore, after normalization, if the valuesent by the card processor 110 is outside such a range (e.g., less than$0.00 or greater than $100.00), then a suitable error message can besent by the system 100 to the card processor 110 providing notificationof the error and, if necessary, a request for corrected data.Additionally, a suitable record of the error can be maintained by thecard product management system 100 (e.g., in an appropriate error log orthe like). Other like suitable data verification and validationtechniques can be performed by the client application server module 115on the normalized data received from each card processor 110. Those ofordinary skill will recognize that the data verification and validationcan be performed by the client application server module 115 eitherbefore or after normalization of the data into the format supported bythe card product management system 100.

Any suitable type of information associated with the card products canbe communicated between the agent portal module 105 and the plurality ofcard processors 110, including, for example, financial information,status, queries, and any other appropriate responses and replies, aswell as information for managing and administering the card products,such as information related to users, enrollment, and the like. Asdiscussed previously, the format of the messages and the information ordata contained within those messages will depend on numerous factors,such as, for example, the communication protocol used by the cardprocessors 110, the nature and type of information associated with thecard products, and other like factors. According to an exemplaryembodiment of the present invention, the information received from eachcard processor 110 can comprise a plurality of reports. For example, asingle report can contain all or substantially all of the relevantinformation associated with one or more card products maintained by thecard product management system 100. Alternatively, multiple reports canbe used, with each report containing a predetermined subset ofinformation associated with the one or more card products.

For example, according to one exemplary embodiment of the presentinvention, three such reports can be used to communicate informationassociated with card products, such as, for example, a “general” report,a “posted” report, and an “authorization” report. The general reportscan include any suitable general or non-financial data associated withthe card products, including, for example, names and addresses ofcardholders, demographic data associated with cardholders, status ofcard products, and other like information. However, the general reportscan also include any suitable financial data, such as, for example, cardbalances and the like. The posted reports can include any suitableinformation regarding posted transactions, such as, for example, alisting of posted transactions from the previous business day or thelike. The authorization reports can include any suitable informationregarding authorizations of financial or other transactions, including,for example, authorization attempts, non-settled transactions and thelike. However, any suitable number of reports, each containing anyappropriate type of information, can be used to communicate informationassociated with the card products, for example, from the card processors110.

For example, FIG. 2 is report specification for a general ornon-financial report 200, in accordance with an exemplary embodiment ofthe present invention. The general report 200 includes several sections,including a header section 205, a detail (body) section 210, and atrailer section 215. The report specification illustrated in FIG. 2describes the fields that can populate the header section 205, thedetail section 210 and the trailer section 215, as well, for example,the maximum length 220 of each field, the format 225 of each field, andthe description 230 of each field within each of the sections. Theheader section 205 can include any suitable header fields, such as, forexample: HEADER (e.g., to specify the start of the header section 205);PROCESSOR NAME (e.g., name of the card processor 110); REPORT/DATA FEEDNAME (e.g., to specify the report as a general or non-financial report200); FILEDATE (e.g., the date the report is received from theprocessor); RUNDATE BEGIN (e.g., the beginning date that the informationin the general report 200 is referencing); and RUNDATE END (e.g., theending date that the information in the general report 200 isreferencing). Additional and/or alternative fields can be included inthe header section 205.

The detail section 210 can include any suitable detail or body fields,such as, for example: CARD NUMBER (e.g., the number on the plasticissued to the cardholder); OPEN DATE (e.g., the date the particular cardwas opened); EXPIRATION DATE (e.g., the expiration date of the card);CARDHOLDER IDENTIFICATION CODE (e.g., a code used to identify thecardholder identification value, such as, for example, “1” for socialsecurity number, “2” for drivers license number, “3” for matricularconsular number, “4” for passport, “5” for visa, “6” for green card orthe like); CARDHOLDER IDENTIFICATION VALUE (e.g., a value used toidentify a customer); PRIMARY CARDHOLDER FIRST NAME; PRIMARY CARDHOLDERLAST NAME; ADDRESS LINE 1; ADDRESS LINE 2 (e.g., first and second linesof cardholder's address); CITY; STATE; ZIP CODE (e.g., city, state andzip code of cardholder's address); PRIMARY PHONE NUMBER; SECONDARY PHONENUMBER (e.g., cardholder's primary and secondary phone numbers); STATUS(e.g., status of a particular card); CURRENT BALANCE (e.g., currentbalance on the card); CURRENT BALANCE SIGN (e.g., sign if balance ispositive (+) or negative (−)); PROGRAM IDENTIFICATION VALUE (e.g., aprocessor assigned value, if applicable); and SUB-PROGRAM IDENTIFICATIONVALUE (e.g., a processor assigned value, if applicable). According to anexemplary embodiment, the CARDHOLDER IDENTIFICATION VALUE field becomprised of a concatenation of sub-fields, including, for example:VALUE (e.g., up to 25 alphanumeric characters specifying anidentification value); COUNTRY (e.g., up to 2 alphanumeric charactersspecifying the country of issuance of the identification); EXPIRATIONDATE (e.g., specified as MMDDYYY, MMYYY, YYYY or the like); and COMMENTS(e.g., up to 50 alphanumeric characters specifying comments). Additionaland/or alternative fields and sub-fields can be included in the detailsection 210. Any suitable number of cards or card products can beconveyed in the general report 200, and each card or card product (e.g.,each account associated with each card or card product) can have adetail record in the detail section 210.

The trailer section 215 can include any suitable trailer fields, suchas, for example: TRAILER (e.g., to specify the start of the trailersection 215); and COUNT (e.g., to specify the number or count of detailrecords contained in the detail section 210). Additional and/oralternative fields can be included in the trailer section 215.

For example, FIG. 3 is report specification for a posted report 300, inaccordance with an exemplary embodiment of the present invention. Theposted report 300 includes several sections, including a header section305, a detail (body) section 310, and a trailer section 315. The reportspecification illustrated in FIG. 3 describes the fields that canpopulate the header section 305, the detail section 310 and the trailersection 315, as well, for example, the maximum length 320 of each field,the format 325 of each field, and the description 330 of each fieldwithin each of the sections. The header section 305 can include anysuitable header fields, such as the same or different header fields asspecified for the header section 205 of the general report 200 (e.g.,with the value of the REPORT/DATA FEED NAME field specifying the reportas a posted report 300).

The detail section 310 can include any suitable detail or body fields,such as, for example: CARD NUMBER (e.g., the number on the plasticissued to the cardholder); TRANSACTION DATE (e.g., the date of theoriginal transaction); TRANSACTION CODE (e.g., a code representing thetype of monetary transaction); TRANSACTION AMOUNT (e.g., the amount ofthe transaction that posted to the card); TRANSACTION AMOUNT SIGN (e.g.,sign if transaction is positive (+) or negative (−), with negative signdesignates removing funds, while positive sign designates adding funds);TRANSACTION CURRENCY CODE (e.g., a code representing the currency of thetransaction amount); AUTHORIZATION CODE (e.g., the identification numberassigned to the approved transaction, and can be blank if theauthorization request was declined); POST DATE (e.g., the date thetransaction posted to the card); NETWORK CODE (e.g., the codeidentifying the Network (e.g., Pulse, NYCE, STAR or the like) rails usedto process the transaction); MERCHANT NUMBER (e.g., a number identifyingthe merchant submitting the transaction); MERCHANT NAME (e.g., the nameof merchant accepting the original transaction); MERCHANT CATEGORY CODE(e.g., a code representing the merchant's line of business); MERCHANTCOUNTRY CODE (e.g., a code representing the country where the merchant'sbusiness is located); INTERCHANGE FEE AMOUNT (e.g., the amount ofinterchange associated with the present transaction); ACH ROUTING NUMBER(e.g., routing number where funds will be distributed); ACH ACCOUNTNUMBER (e.g., account number where funds will be distributed); and ACHCONFIRMATION NUMBER (e.g., a confirmation code for the ACH transactionthat can appear on the cardholder's statement where the funds are beingdistributed). Additional and/or alternative fields and sub-fields can beincluded in the detail section 310. The trailer section 315 can includeany suitable trailers fields, such as the same or different trailerfields as specified for the trailer section 215 of the general report200.

For example, FIG. 4 is report specification for an authorization report400, in accordance with an exemplary embodiment of the presentinvention. The authorization report 400 includes several sections,including a header section 405, a detail (body) section 410, and atrailer section 415. The report specification illustrated in FIG. 4describes the fields that can populate the header section 405, thedetail section 410 and the trailer section 415, as well, for example,the maximum length 420 of each field, the format 425 of each field, andthe description 430 of each field within each of the sections. Theheader section 405 can include any suitable header fields, such as sameor different header fields as specified for the header section 205 ofthe general report 200 (e.g., with the value of the REPORT/DATA FEEDNAME field specifying the report as an authorization report 400).

The detail section 410 can include any suitable detail or body fields,such as, for example: CARD NUMBER (e.g., the number on the plasticissued to the cardholder); TRANSACTION DATE/TIME (e.g., the date andtime of the original transaction); TRANSACTION CURRENCY CODE (e.g., acode representing the currency of the transaction amount); ADDRESSVERIFICATION RESPONSE (e.g., a message representing the response ifaddress verification was utilized); AUTHORIZATION RESPONSE (e.g., amessage representing why the request was authorized or declined);AUTHORIZATION AMOUNT (e.g., the amount of the authorization request);AUTHORIZATION CODE (e.g., the identification number assigned to theapproved transaction, and can be blank if the authorization request wasdeclined); NETWORK CODE (e.g., the code identifying the Network (e.g.,Pulse, NYCE, STAR or the like) rails used to process the transaction);MERCHANT NUMBER (e.g., a number identifying the merchant submitting thetransaction); MERCHANT NAME (e.g., the name of merchant accepting theoriginal transaction); MERCHANT CATEGORY CODE (e.g., a code representingthe merchant's line of business); and MERCHANT COUNTRY CODE (e.g., acode representing the country where the merchant's business is located).Additional and/or alternative fields and sub-fields can be included inthe detail section 410. The trailer section 415 can include any suitabletrailers fields, such as the same or different trailer fields asspecified for the trailer section 215 of the general report 200.

As discussed above, BINs are assigned to card processors 110 by cardissuers. For example, a BIN or other unique identifier can be assignedto each card processor 110 by MASTERCARD™ or VISA™ or other cardissuers. The card processors 110 associate BINs to the card products.The BINs can be used to uniquely identify the card processor 110 thatservices and/or processes a particular card product. For theillustration of bank-issued gift cards or the like with sixteen-digitcard product numbers, the first six digits of the card product numbercan comprise the BIN, although any suitable number of digits can be usedto specify the BIN. Conventionally, the remaining digits of the cardproduct number can be used to uniquely identify a user (e.g., thecardholder), and are also assigned by the card processors 110. For theillustration of bank-issued gift cards or the like, the remaining (e.g.,ten) digits are commonly used for assigning a BIN extension (e.g., sixdigits), a card number (e.g., three digits), and a check bit (e.g., onedigit). The entire card product number thereby uniquely identifies boththe card processor 110 that services and/or processes the card productand the cardholder of that card product.

However, according to an alternative exemplary embodiment of the presentinvention, the client application server module 115 can be configured toallocate and assign card numbers corresponding to each BIN (or otherunique identifier) for the card products. More particularly, the cardproduct number can be comprised of two portions of digits—a firstportion of digits and a second portion of digits. For purposes ofillustration and not limitation, for a sixteen digit card product numberfor, for example, a bank-issued gift card or the like, the first portionof digits can include the first six digits of the card product number,while the second portion of digits can include the remaining ten digits.The first portion of digits can comprise the BIN (or other suitableunique identifier). For each BIN, the second portion of digits can beused to assign card numbers for the given BIN. The client applicationserver module 115 can allocate card numbers comprising all orsubstantially all of the second portion of digits for each BIN, althoughthe client application server module 115 can use any subset of thesecond portion of digits to allocate card numbers.

In other words, according to an exemplary embodiment, the clientapplication server module 115 can be configured to allocate and assigncard numbers for each BIN (or other suitable unique identifier) by usingall or substantially all of the remaining digits other than the BIN in acard product number. For the example of a sixteen-digit card productnumber with a six-digit BIN, the remaining ten digits (or any subsetthereof) can be used to assign any of one billion card numbers for aparticular BIN. Consequently, for a sixteen-digit card product numberwith a six-digit BIN and ten remaining digits, up to one billion cardproducts can be issued for each card processor 110, although the numberof available card numbers will depend on such factors as, for example,the length of the card product number used, the length of the BIN orother identifier that forms part of the card product number, and otherlike factors. Thus, a “non-processor,” in particular the card productmanagement system 100 according to exemplary embodiments, can allocateand assign values (e.g., card numbers) to the entire second portion ofdigits, or any subset thereof, of the card product number of each cardproduct. For example, the card numbers for the second portion of digitscan be allocated sequentially or randomly for each BIN. Accordingly toan exemplary embodiment, the first portion of digits can precede thesecond portions of digits within each card product number. According toan alternative exemplary embodiment, the second portion can precede thefirst portion of digits. Alternatively, the first and second portions ofdigits can be suitably interleaved or mixed within the card productnumber. The length (in digits) of the card product number and the sizesof the corresponding first and second portions of digits will depend onsuch factors as, for example, the type of card number used for each cardproduct, the size or length (in digits) of the BIN or other uniqueidentifier, the size or length (in digits) of corresponding cardnumbers, and other like factors. According to a further exemplaryembodiment, the client application server module 115, rather than thecard issuers, can allocate and assign the BINs to each card processor110.

Suitable and appropriate methods and mechanisms can be used to ensurethe safety and security of the information communicated between theagent portal module 105 and the card processors 110. For example, secureconnections (e.g., via HTTPS or the like) can be maintained between theagent portal module 105 and each of the card processors 110.Additionally or alternatively, the data and information can be suitablyencrypted using any appropriate encryption or cryptographic algorithm ortechnique, including, for example, any suitable public keyinfrastructure (PKI) system, RC4, MD5, base64 encoding or the like.

Messages communicated to the card processors 110 can include, forexample, a query or the like that includes a computer network address(e.g., a URL, IP address or the like) of a file. For example, the querycan comprise a conventional search query sent by the agent portal module105 to obtain a file or other data located at a particular website URLor other unique address. However, if intercepted, a malicious hacker orintruder can potentially tamper with the query. For example, the URL orcomputer network address could be modified to obtain a different file ordata, such as a secure file or data that is not meant to be accessed orobtained by the card processors 110. Such malicious activity couldrender data maintained by the card processors 110 and the card productmanagement system 100 vulnerable to theft or corruption.

According to an exemplary embodiment, to address such security issues,the computer network address contained in the query can be encrypted.The encrypted computer network address is then appended to the end ofthe query. By appending the encrypted computer network address to theend of the query, the query can be processed (e.g., by the cardprocessors 110) in a conventional manner (while ignoring the appendedencrypted computer network address) to obtain the file or data at thespecified computer network address. The response to the query (e.g.,sent to the agent portal module 105) can also include the query itself,with the computer network address and encrypted computer network addressin the response. The client application server module 115 is configuredto detect tampering with the computer network address by decrypting theencrypted computer network address, and then comparing the computernetwork address and the decrypted computer network address. If bothcomputer network addresses are the same, no tampering has occurred.However, if the computer network address does not match the decryptedcomputer network address, tampering has occurred. In such an instance,suitable security measures can be undertaken (e.g., deletion of themessage), and appropriate alerts and warnings can be communicated toaffected clients.

According to an alternative exemplary embodiment, the client applicationserver module 115 is configured to detect tampering with the computernetwork address by re-encrypting the computer network address, and thencomparing the re-encrypted computer network address and theoriginally-encrypted computer network address (that had been appended tothe end of the query). If the original and newly-encrypted computernetwork addresses are different, then tampering has occurred. Forpurposes of illustration and not limitation, to create an encryptedcomputer network address according to such an alternative exemplaryembodiment, a MD5 hash of a RC4 encryption of the query string of a URLcan be performed to generate an encrypted hash. The encrypted hash canbe appended to the query string as a unique key-value pair. To check thevalidity of an encoded query string, the unique key-value pair hash canbe removed from the query string. A MD5 hash of a RC4 encryption of theremaining query string can be created. The result of the encryption canbe compared to the unique key-value that was previously removed from thequery string. If the two encrypted hashes are different, then tamperingof the query string has occurred.

Any suitable encryption technique can be used to encrypt the computernetwork address. For example, according to an exemplary embodiment, acryptographic hash function can be used. As illustrated previously, thecomputer network address can be encrypted (e.g., using RC4, MD5, base64or the like or any suitable combination thereof) to generate a encryptedcomputer network address. A suitable hash function can then be appliedto the encrypted computer network address to generate an encrypted hash.Although computer network addresses have been discussed, it is notedthat any suitable data within the query, including the entire queryitself or any part thereof, can be encrypted and appended to the end ofthe query for purposes of detecting tampering according to the exemplaryembodiment.

To maintain and administer the card products, the card productmanagement system 100 includes a database module 120 in communicationwith the client application server module 115. The database module 120is configured to store, for example, information associated with thecard products and other like information. The client application servermodule 115 can query or otherwise access the database module 120 tostore or retrieve such information according to requests from users, thecard processors 110, or the system 100 itself. For example, the databasemodule 120 can be used to store tables of card numbers corresponding toeach BIN and other like information to support the management andadministration of card products. The database module 120 can be anysuitable type of computer database or storage medium or memory, databaseproduct (e.g., SQL) that interacts with any such medium or memory, orother like electrical or electronic storage device or facility that iscapable of storing electrical and electronic information for laterretrieval.

According to exemplary embodiments, card processors 110, cardholders,administrators, and other entities and individuals (collectivelyreferred to as “users”) can access information regarding card productsthrough the card product management system 100. In other words, theagent portal module 105 is configured to allow access by users to manageinformation associated with the card products. To support such access,the agent portal module 105 includes a graphical user interface module130. The graphical user interface module 130 is configured to display,either locally or remotely, a graphical user interface (GUI) throughwhich users can interact with the card product management system 100.The GUI can be, for example, a proprietary graphical interface, anysuitable Web browser (e.g., Internet Explorer, Netscape, Firefox,Safari, Opera, or any other suitable Web browser) or other likeinterface that is capable of displaying graphical and/or textualinformation, and can support secure connections and remote access to thecard product management system 100. For example, a Personal Computer(PC) 140 or other suitable type of computer system or device (e.g.,laptop, personal digital assistant (PDA), cellular phone or the like)can be used by a cardholder 143, a financial institution 147 or otherlike user to remotely access information regarding card products throughthe card product management system 100 using the GUI of the graphicaluser interface module 130, for example, through a suitable Web browservia a secure connection over the Internet or World Wide Web.

The GUI can support a login screen that prompts users to enter ausername (or e-mail address) and a uniquely-assigned password to gaininitial access to the card product management system 100 upon successfulentry of both. Passwords can be encrypted using any suitable encryptiontechnique (e.g., MD5 or the like), and users can be locked out of thesystem after three unsuccessful attempts to log in. Other suitableadditional or alternative security measures can be used for logging intothe system 100, including, for example, biometrics and the like.According to an exemplary embodiment, the graphical user interfacemodule 130 is configured to determine the computer network address ofthe user (e.g., the IP address of the computer from which the user isaccessing the system 100). As an additional security feature, thegraphical user interface module 130 can compare the computer networkaddress of the user with a computer network address that has been storedfor the user's username (e.g., an IP address that is entered orotherwise recorded for the user at the time of enrollment orregistration with the system 100). In addition to the username andpassword, if the computer network address of the user does not match therecorded computer network address corresponding to the user's username,then access to the card product management system 100 can be denied.Thus, the user can be granted access to the card product managementsystem 100 through the GUI using both or either of the password and theassociated computer network address of the user.

The card product management system 100 is a role-based system. In otherwords, the functionality, features and information presented to andaccessible by each user through the GUI can be based on the user'sestablished role with the system 100. For example, a cardholder can begiven access to and manage information that pertains only to the cardproducts held by the cardholder. In contrast, a card processor 110 canbe given access to and manage information that pertains to all cardproducts issued by that card processor 110. However, an administrator ofthe card product management system 100 can be given access to and manageinformation that pertains to all card products maintained by the system100. In each instance, the GUI is configured to allow the given user toaccess only those features, functionality and information that areappropriate for the user given that user's role in the card productmanagement system 100.

To assist in such a delineation of functionality between various users,each type of user can access the card product management system 100 viadifferent website addresses (e.g., URLs). For example, cardholders canaccess the system 100 by navigating their Web browsers to a site suchas, for example, “myprepaidbalance.com” or “myprepaidaccount.com” orother suitable website address. Card processors 110 can access thesystem 100 by directing their Web browsers to a different address, suchas, for example, “prepaidadmin.com” or other suitable website address.Although different URLs can be used for each type of user, each websiteaddress still leads the respective user into the card product managementsystem 100, albeit through different entrance points.

Additionally or alternatively, the GUI can be configured to present adifferent theme, appearance or “skin” to the user, depending on theuser's role and/or affiliation with a card processor 110. For example,based on the user's identification via their corresponding username andpassword (and, if desired, computer network address), the graphical userinterface module 130 can change the configuration of the appearance ofthe GUI displayed to the user. For example, for cardholders, the GUI canbe quite “showy” or otherwise elaborately decorated to enhance thecardholder's experience. In addition, advertisements, promotions,marketing information, usage tips, navigation information and the likeof potential interest to the cardholder can be displayed through the GUIto the cardholder. In contrast, an administrator can be presented with aGUI that is more “stark,” focusing on features and functionality, ratherthan on elaborate presentation. Furthermore, each card processor 110 canhave an associated theme or “skin” for the GUI. Thus, when a cardprocessor 110 logs into the card product management system 100 throughthe GUI, the corresponding graphical theme or “skin” of that cardprocessor 110 can be displayed. Such a theme or “skin” can also oralternatively be presented to users (e.g., cardholders) when managingcard products issued by that card processor 110.

Upon gaining access, users of the card product management system 100 canview and manage the information associated with card products. The cardproduct management system 100 is configured to allow users to performthose functions associated with managing card products. For example, fora “plastic order,” users can order the plastic cards that are(ultimately) distributed to cardholders, including specifying the designor layout of the cards, providing custom messages to appear on thecards, and other like features of the cards. Once the user has purchasedthe actual, plastic cards through the system 100, the cards can beloaded with value (e.g., a dollar amount), activated and issued. For theillustration of gift cards, using an “instant issue,” an individual cardcan be assigned, for example, a card number, expiration date, loadamount, CVV2/CVC2 number, security code and other identifyinginformation. The individual card can then be registered using thecardholder's name, address, telephone number and the like. The card isthen ready for use by the cardholder. In addition, a “bulk order” can beconsidered a combination of “plastic order” and “instant issue.” For abulk order, the plastic cards are ordered and can be pre-loaded with amonetary amount that can be accessed upon activation of the cards. Thus,such bulk orders can allow a user to both specify card load amounts atthe time of order and to personalize/customize those cards for sale ordistribution.

It is noted that any suitable types of card or card-based products canbe offered or otherwise sold or distributed through the card productmanagement system 100. For a particular type of card product, each ofthe individual cards of the given card product type can be servicedand/or processed by any of the card processors 110. In other words, onecard product type can use multiple card processors 110. For example,assume that a card issuer has a card stock of card product type X. Afirst order of cards of card product type X can be assigned a first BINor other unique identifier to be serviced and/or processed by the firstcard processor 110. A second order of cards of card product type X canbe assigned a second BIN or other unique identifier to be servicedand/or processed by the second card processor 110. A third order ofcards of card product type X can be assigned a third BIN or other uniqueidentifier to be serviced and/or processed by the third card processor110. Thus, although each individual card is serviced and/or processed bya particular card processor 110, any of the card processors 110 can bechosen to service and/or process the cards of a particular card producttype.

The card product management system 100 can allow the user to viewprevious orders. For example, FIG. 5 is an example of a graphical userinterface (GUI) 500 for viewing orders through the card productmanagement system 100, in accordance with an exemplary embodiment of thepresent invention. The GUI 500 can display suitable information tosummarize, for example, all or the most recent orders for plastic orders505, instant issues 510 and bulk orders 515. The summarized informationcan include, for example, order number, date of order, client name,program name, product name, status of order, total quantity of cardsordered, total load amount and any other suitable information. Inaddition, a search field 520 is configured to allow the user to searchand filter (using standard searching and filtering algorithms andtechniques) the order history according to any of the previous mentionedsummarized information, and including such additional fields as customernumber, cardholder name, company name, company phone, card number, taxID, cardholder's date of birth, zip code, security code and the like. Byusing such searching/filtering, the user can view any desired level ofgranularity of the card product information, from individual cards toentire card orders across any or all of the card processors 110.

The card product management system 100 is also configured to generatereports for the information associated with the card products. Forexample, the client application server module 115 can format the reportsbased on user requests, which can then be displayed through the GUI bythe graphical user interface module 130. Any suitable type of report canbe provided by the system 100 to the user including, for example, anorder summary for the user, a total sales summary, a total sales summaryby branch, a plastic order summary, an inventory summary, card details,a listing or summary of ACH requests and the like. According to anexemplary embodiment, each report can be populated with information inaccordance with the identification of the user. In other words, oncelogged into the system 100, the identity of the logged-in user is knownto the card product management system 100 via the user's username andpassword. Since the user's identity is known, card product informationfor that user can be presented or otherwise displayed to that userthrough the GUI, for example, in the form of reports. In addition,because the user' identity is known, the GUI itself can be configured todisplay other information associated with the given user, such as, forexample, a list of products available to that user, GUI menu functions(e.g., pull-down or pop-up menus and sub-menus) that are available tothat user, and the like. For example, card products can be presented tothe user through the GUI based on the user's identification and theuser's association or affiliation with a financial institution such as acard processor 110. Thus, the card product management system 100 cantailor the interface and information presented to each user (e.g., basedon the user's identity) to improve the ease of use of and accessibilityto the system 100 and the card product information maintained by thesystem 100.

For purposes of illustration and not limitation, FIG. 6 is a diagramillustrating a transaction flow for a gift card issued by a cardprocessor 110, in accordance with an exemplary embodiment of the presentinvention. FIG. 6 illustrates the interaction between cardholders, salesagents (e.g., those who sell and distribute cards at points of sale),processors and the card product management system 100. In block 605, theconsumer purchases a gift card from a sales agent at the point of sale.In block 610, the sales agent enters the transaction information intothe Web-based application (e.g., the GUI) of the card product managementsystem 100 and transmits the sales data to the card processor 110 whoissues the given gift cards. In block 615, the card processor 110validates the transaction, loads value to the card account and activatesthe card. In block 620, the card processor 110 transmits anauthorization back to the sales agent. In block 625, the card processor110 creates and sends daily files to the financial institution (e.g., abank or the like) for funds movement, including value loads, sales, andthe like. In block 630, the sales agent gives the customer the (loadedand activated) gift card, appropriate fee disclosures and cardholderagreements, receipt and the like. According to an exemplary embodiment,such (printed) consumer disclosures can be viewed electronically by theconsumer or other user through the system 100 via the GUI, as the system100 is configured to electronically store (e.g., in the database module120) such disclosures and other documentation for access by users.

In block 635, the sales agent deposits the proceeds of the sale into thesales agent's bank account. In block 640, the bank or other financialinstitution creates an ACH file to settle with the sales agent, andholds the finds on behalf of the cardholder. After the consumer is giventhe “live” gift card in block 630, then in block 645 the consumer (nowcardholder) can use the card immediately to purchase goods and servicesat millions of locations where the major brand of the gift card isaccepted. In block 650, the cardholder can interact with the cardproduct management system 100 through the GUI to get updated cardbalance information (e.g., via a URL listed on the back of the giftcard). According to an alternative exemplary embodiment, the cardholdercan interact with the system 100 through a telephone using a suitableinteractive voice response (IVR) system or the like, instead of the GUI.

Referring to FIG. 1, the card product management system 100 includes amanagement application server module 125. The management applicationserver module 125 is in communication with the database module 120.According to exemplary embodiments, the management application servermodule 125 is configured to manage any and all aspects of the cardproduct management system 100 and the card products maintained by thesystem 100. For example, the management application server module 125 isconfigured to monitor card product activity and provide sales andexception reporting on a daily basis. For example, sales activity thatappear on multiple exception reports can be reviewed for possiblesuspicious activity. Exception reports can include, for example,high-dollar transactions, velocity checks for value loads andtransactions, excessive credits or returns, foreign transactions andother like activity that may be suspicious. In addition, balance andinactivity timeframes for each card product can be monitored daily bythe management application server module 125. Transaction settlementsare automated, and funding account balances can be monitored daily foradequacy by the management application server module 125. The managementapplication server module 125 is configured to monitor any and all cardproduct accounts and automate the escheatment process on a state bystate basis. Thus, the management application server module 125 canmonitor, track and report on card processors 110, users, programs,vendors, contracts and the like on a daily or other timely basis.

Administrators and other appropriate users can access and manage thesystem 100 and view information associated with card products using themanagement application server module 125 via a suitable GUI, such as thesame or different GUI provided by the graphical user interface module130 of the agent portal module 105. According to an exemplaryembodiment, the GUI for the management application server module 125 isa separate GUI that is provided by a second graphical user interfacemodule or the like that is a component of the management applicationserver module 125. However, the graphical user interface module 130 canprovide GUIs for both the agent portal module 105 and the managementapplication server module 125.

The management application server module 125 can display any suitableinformation to administrators and other like users in any appropriateformat or configuration for managing the card product management system100. For example, FIG. 7 is an illustration of an overview page 700 forthe management application server module 125, in accordance with anexemplary embodiment of the present invention. The overview page 700 canprovide brief summary information on, for example, counts of cardprocessors 110, clients, program and vendors by status, card productdata, and program breakdown by association. For example, the overviewpage 700 can display a card summary 705, status summary 710, programlaunch date summary 715, and association summary 720. Other likeinformation can be displayed on the overview page 700, such as, forexample, a card product (e.g., gift card) summary or the like. Theoverview page 700 is configured to display a top-level menu 730 of otherpages to which the administrator can navigate to obtain more detailedinformation, including tabs for accessing, for example, “Processors,”“Clients,” “Programs,” “Vendors,” “Entity,” “Contacts,” “Materials,”“Contracts,” “Funding,” “Reports,” “Tools,” and other suitableinformation. Several of such exemplary menu items will be discussed.

Selecting the “Processors,” “Clients,” “Programs,” or “Vendors” tabs canbring the administrator to a listing page for that entity type. FIGS.8A, 8B and 8C illustrate a processor page 805, a clients page 810 and aprograms page 815, respectively, in accordance with an exemplaryembodiment of the present invention. Each such listing page can providethe ability to quickly search for or navigate to the appropriatedetailed information. Each listing page lists data such as, for example,the name and relevant summary data for each entity. According to anexemplary embodiment, clicking or otherwise selecting the entity name(e.g., via mouse or suitable pointer device input) from the list cantake the administrator to a detailed page for that entity.

For example, FIG. 9 illustrates a client detail page 900, in accordancewith an exemplary embodiment of the present invention. The client detailpage 900 can be accessed by, for example, selecting the “Clients” tab inthe top-level menu 730 and the “Detail” tab 902 in the correspondingsub-menu. Each detail page is configured to provide an overview of theentity, and can be used to add and edit data associated with the entity.For example, client detail page 900 can maintain such data as clientdetail information 905, client program data 910, client project plans915 and the like. Other like information can be displayed in the clientdetail page 900, including, for example, client contacts (e.g., name,title, phone number, contact type and the like), client contracts,client addresses, client statement definitions, client relationships(e.g., agents, co-branders, distributors, locations, marketers,servicers and the like) and other suitable information, such as, forexample, client locations, child clients, commission clients andproducts and the like.

From each tab on the overview page 700, an administrator can drill-downto more detailed information associated with each tab. For example, FIG.10 illustrates a program details page 1000, in accordance with anexemplary embodiment of the present invention. By selecting the“Programs” tab in the top-level menu 730, the administrator can bepresented with an appropriate sub-menu 1005 of page listing options forthe given tab. For example, for the “Programs” tab 1010, thecorresponding sub-menu 1005 can include such additional tabs as“Details,” “Contacts,” “Notes,” “Project Plans,” “Attributes,”“Funding,” “Products,” “Contracts,” “Relationships,” “Locations,”“Quality” and the like. By selecting the “Details” tab 1015 of thesub-menu 1005, the administrator can be presented with the programdetails page 1000. The program details page 1000 can display anysuitable program detail information, such as, for example, name, client,program type, association, processor, status and other like information.The administrator can use such a listing page for adding and editingprogram information for an entity. Other tabs or items in the sub-menu1005 can be selected by and displayed to the administrator.

For example, FIG. 11 illustrates a client contracts page 1100, inaccordance with an exemplary embodiment of the present invention. Byselecting the “Clients” tab in the top-level menu 730, the administratorcan be presented with an appropriate sub-menu 1102 of page listingoptions for the given tab (which can be a similar or different listingof options from sub-menu 1005 illustrated in FIG. 10). For example, forthe “Clients” tab 1101, the corresponding sub-menu 1102 can include suchadditional tabs as “Detail,” “Contacts,” “Addresses,” “Notes,” “ProjectPlans,” “Funding,” “Programs,” “Contracts,” “Relationships,”“Locations,” “Quality” and the like. By selecting the “Contracts” tab1103 of the sub-menu 1102, the administrator can be presented with theclient contracts page 1100. According to an exemplary embodiment, theadministrator can make an entry through the management applicationserver module 125 via the contracts page 1100 when each contract issigned. Information recorded in the contracts page 1100 includesrelevant details and dates associated with the contract. For example,action dates 1105 can be provided. A notice date field 1110 under theaction dates 1105 can be set to six months (or other suitable timeperiod) prior to the expiration date 1115 to allow for re-negotiation ornotice of termination. Once the notice date is reached, the managementapplication server module 125 can send an e-mail or other suitablenotification to the user listed as a notify contact 1120, with suchnotifications being sent daily or periodically until appropriate actionis taken. Additionally, an e-mail or other suitable notification canalso be sent to the appropriate operations department or personnel tonotify them of the new contract and prompt them to enter a statementdefinition for that contract. Other like information can be displayed inthe contracts page 1100, including, for example, accompanying notes thatcan be added for the contract. Other tabs or items in the sub-menu 1102can be selected by and displayed to the administrator.

For example, by selecting the “Quality” tab of the sub-menu 1102, theadministrator can be presented with the client quality page 1200. FIG.12 illustrates a client quality page 1200, in accordance with anexemplary embodiment of the present invention. The clients quality page1200 under the “Quality” tab 1205 can display information for trackingdue diligence, quality review and appropriate corporate documentationand other like information for a client. For example, the due diligencesection 1210 can be completed when information on the entity is entered.The review section 1215 can provide the card product management system100 with a date by which a review will be needed based on the client'srisk rating. The tracking section 1220 can indicate the documentationand other information required for performing due diligence, and thedate of the most recent version of such documentation that is on file. Areport can be generated by the management application server module 125to track what documentation is required annually (or other suitable timeframe) from the entity.

Returning to display or listing options under the “Programs” tab 1010 inthe top-level menu 730, FIG. 13 illustrates a program project plans page1300, in accordance with an exemplary embodiment of the presentinvention. The project plans page 1300 can be accessed by, for example,selecting the “Programs” tab 1010 in the top-level menu 730 and the“Project Plans” tab 1301 in the corresponding sub-menu 1005. The programproject plans page 1300 can guide the administrator through apre-defined process for setting up a card processor 110 or program. Theprogram plans page 1300 can allow the administrator to enter anysuitable project plan task names 1305 corresponding to each task. Forexample, when a new project plan is created, the management applicationserver module 125 can calculate the start and end dates 1310 and 1315,respectively, for each task name 1305. The administrator can also enterthe actual start date and end dates 1320 and 1325, respectively, foreach task name 1305. Each task can be disabled if it is not needed byappropriately de-selecting the task name 1305. Notes 1330 can be enteredfor each task name 1305. Time 1335 can be tracked for each task name1305, and billable time entries can become, for example, a line item onthe client's statement or invoice.

Also under the “Programs” tab 1010 in the top-level menu 730, FIG. 14illustrates a program funding page 1400, in accordance with an exemplaryembodiment of the present invention. The funding page 1400 can beaccessed by, for example, selecting the “Programs” tab 1010 in thetop-level menu 730 and the “Funding” tab in the corresponding sub-menu1005. The program funding options 1405 on the program funding page 1400can display the date that the system 100 will need to automaticallygenerate the ACH funding for the program. For example, every postedtransaction that is on the posted report 300 of the card processor 110can be stamped with a transaction type. When purchase funding is turnedon, ACH records can be created each day (or suitably periodically) tomove the funds at a program level from settlement to funding or fundingto settlement based on the transaction sign. For example, a posting timeoffset 1410 can inform the system 100 to adjust the time of thetransaction by a number of hours (or other appropriate time period) sothat the transaction can roll up to the appropriate business day. Otherlike information can be displayed on the program funding page 1400. Forexample, FSA benchmark parameters can include benchmark values andfunding percent that can be used to maintain the appropriate funding inthe account. The benchmark value can be increased automatically whenmore value is loaded to the program. The funds can be replenishedperiodically (e.g., daily) based on purchases. Bank accounts 1430 can beassigned for each type of funds movement that is going to occur in thefinding options 1405 section.

Further under the “Programs” tab 1010 in the top-level menu 730, FIG. 15illustrates a program attributes page 1500, in accordance with anexemplary embodiment of the present invention. The program attributespage 1500 can be accessed by, for example, selecting the “Programs” tab1010 in the top-level menu 730 and the “Attributes” tab 1501 in thecorresponding sub-menu 1005. The program attributes page 1500 can allowadministrators to set values that can be used to manage thefunctionality of the program. For example, an administrator can use suchvalues to enforce restrictions on the card products, including, forexample, the minimum load amount (e.g., minimum load amount 1505 forinstant/personalized orders, minimum load amount 1515 for bulk orders),the maximum load amount (e.g., maximum load amount 1510 forinstant/personalized orders, maximum load amount 1520 for bulk orders),expiration date (e.g., expiration date 1525 for instant/personalizedorders, expiration date 1530 for bulk orders), client fees 1535 per cardproduct (including, for example, minimum and maximum client fees percard product 1540 and 1545, respectively), and other like attributes.

The management application server module 125 is configured to displayvarious suitable types of reports to an administrator or otherappropriate users. FIG. 16 illustrates a gift card report page 1600, inaccordance with an exemplary embodiment of the present invention. Byselecting the “Reports” tab 1610 in the top-level menu 730, theadministrator can be presented with an appropriate sub-menu 1615 ofreport options for the given tab. For example, for the “Reports” tab1610, the corresponding sub-menu 1615 can include such additional tabsas “Files,” “Financial,” “Exception,” “Statements,” “Time Tracking,”“NCR Translation,” “Gift Card,” “Quality,” “Client Services,”“Development” and other like reports. For purposes of illustration andnot limitation, by selecting the gift card tab 1620 of the sub-menu1615, the administrator can view or generate various types of reportsfor gift cards (or other card products) and supporting tools, including,for example, gift card workflow 1625 (e.g., work queues, enrollments,orders pending funding, orders awaiting card numbers, orders ready forembossing, orders awaiting activation and the like), reports 1630 (e.g.,commission client entries, commission payable summary, program reportingrollup, order funding exceptions, processor client summary, clientmaster list, plastic inventory, lost/stolen cards, “cashed-out” cards,complete order overview, available card number pool, order summary bystatus and other like reports) and gift card tools 1635 (e.g., cardinquiry and the like). For example, a gift card order summary reportpage can display a summarized listing (e.g., by day, week, month or thelike) of any or all gift card orders, including such information asorder number, date of order, type of order, status of order, client,quantity, total load amount, plastic fees, adjustments, total amount,and other like information.

Continuing with the present illustration, with respect to the exemplarytypes of reports that can be viewed for gift cards (or other cardproduct products) from gift card report page 1600, FIG. 17 illustrates awork queue report page 1700 selected from the list of the gift cardworkflow 1625, in accordance with an exemplary embodiment of the presentinvention. An administrator can use the work queue report page 1700 to,for example, approve, decline, move and monitor enrollments, bulk andplastic orders and the like for, for example, a gift card or othersuitable card product program. Some of the types of information that canbe viewed on the work queue report page 1700 includes enrollments 1705.For example, online enrollments can be completed by sales agents foreach new card product client, which can initiate the appropriatecontract, due diligence and program setup by the card product managementsystem 100. Orders pending funding 1710 can display those orders thatneed funding verified and/or approved. Funded orders awaiting cardnumbers 1715 can present a list of orders that require card numberscreated and assigned (e.g., in the manner described previously forallocating and assigning card numbers). Funded orders awaiting embossing1720 includes a display of orders that need to be sent to an embosser.Orders awaiting embosser return file 1725 can list the orders at theembosser that require a result file or the like to be processed. Othersuitable information can be displayed on the work queue report page1700, including, for example, bulk orders awaiting customer activationrequest 1727 (e.g., a list of orders in route to the customer that arewaiting for the customer to initiate the activation and load of the cardproduct), orders awaiting activation by the system 100 (e.g., a list oforders that have been received from the customer and the customer hasrequested activation and load of the card product), and other likeinformation. It is also noted that a range of available card numbersaccording to exemplary embodiments can be displayed in the funded ordersawaiting card numbers 1715, for example, providing the start 1730 andend 1735 card numbers (e.g., where the first six digits of a cardproduct number comprises a BIN, and the remaining ten digits—0000000000to 9999999999—are available for card number allocation).

FIG. 18 illustrates a commission payable summary report page 1800, inaccordance with an exemplary embodiment of the present invention. Thecommission payable summary report page 1800 can be accessed from thereports 1630 section of the gift card report page 1600. For example,gift card commission payable summary 1805 can display and track any orall commissions paid at the order type level or the like. According toan exemplary embodiment, a commission entry can be automaticallygenerated for the sales agent when an enrollment is approved by thesystem 100. Commissions can be sent via ACH or other suitable means forelectronic funds transfer to the sales agent. The administrator canfilter the information displayed on the gift card commission payablesummary 1805 by entering appropriate report criteria in the reportfilter criteria section 1810 to view any suitable additional oralternative subset of the gift card commission payable summary 1805.

Other reports can be generated and viewed by selecting the appropriatetab or menu item of the “Reports” tab 1610, such as a listing of“Files.” For example, FIG. 19 illustrates a report files page 1900, inaccordance with an exemplary embodiment of the present invention. Thereport files page 1900 is accessed by selecting the files tab 1905. Asdiscussed previously, the system 100 can receive any suitable number ofreports from each card processor 110, including, but not limited to, forexample, a general or non-financial report 200, a posted report 300 andan authorization report 400. Such data can be loaded into a centralrepository (e.g., database module 120) and each transaction listed inthe reports can be stamped with a common transaction code and producttype defined by the system 100. The status of each report file can bemonitored during the load process using the report files page 1900. Foreach card processor 110, the report files page 1900 can list whethereach of the general report 200, posted report 300 and authorizationreport 400 was received 1910, processed 1915 and/or loaded 1920. Asnoted above, data in the reports can be validated against, for example,a translation matrix for each card processor 110 that is defined by thecard processor 110 and system 100 during the processor setup. Any errorsfound in any of the reports can be researched and corrected before thedata is accepted. Once all of the data is successfully loaded into thedatabase module 120, the system 100 can initiate ACH requests or othersimilar funds transfer procedures for periodic (e.g., daily) fundsmovement. The administrator can filter the information displayed on thereport files page 1900 by entering appropriate report criteria in thereport filter criteria section 1925 to view any suitable additional oralternative subset of the report files information. Thus, the cardproduct management system 100 can report collected data across anycombination of programs, clients, processors, associations, transactiontypes and the like.

To monitor funds movement, the administrator can select a “Financial”tab under the “Reports” tab 1610. FIG. 20 illustrates a financial reportpage 2000, in accordance with an exemplary embodiment of the presentinvention. The financial report page 2000 is accessed by selecting thefinancial tab 2005 in the sub-menu 1615. Funds movement can be based onfunding rules defined at the time of program setup and the periodic(e.g., daily) transaction data. ACH requests or other suitable fundstransfer requests can be based on, for example, aggregate moneymovements for each program by transaction type and sign. The managementapplication server module 125 can reconcile requested ACH amountsagainst calculated amounts and report discrepancies. Additionally, themanagement application server module 125 is configured to recognize pre-and post-dated transactions, and can initiate ACH requests or othersuitable funds transfer requests accordingly. Thus, the financial reportpage 2000 can display information to the administrator or otherappropriate user for each card processor 110, such as, for example,settlement date, transaction type, sign of the transaction (e.g.,indicating credit or debit), the type of accounts from and to funds willbe transferred, amount of the transfer, ACH amount, status of transferand other suitable information. The administrator can filter theinformation displayed on the financial report page 2000 by enteringappropriate report criteria in the report filter criteria section 2010to view any suitable additional or alternative subset of the financialinformation.

Additionally, the financial report page 2000 can display a listing ofaccount reconciliations and other similar information. FIG. 21illustrates an account reconciliation report page 2100, in accordancewith an exemplary embodiment of the present invention. Periodically(e.g., each day), the system 100 can load daily or periodic GL (GeneralLedger) and DDA (Demand Deposit Account) account activity and othersuitable information. The management application server module 125 isconfigured to systematically reconcile each transaction against theoriginal ACH request created by the daily or periodic funds movementprocess. The administrator can review such information and make manualreconciliation entries where necessary, and systemic entries can beedited by the administrator, if necessary. Again, the administrator canfilter the information displayed on the account reconciliation page 2100by entering appropriate report criteria in the report filter criteriasection 2110 to view any suitable additional or alternative subset ofthe account reconciliation information.

For each card processor 110 or other client, customer or user, the cardproduct management system 100 can generate appropriate statements orinvoices for card products purchased using the system 100. FIG. 22illustrates a statement 2200 generated by the card product managementsystem 100, in accordance with an exemplary embodiment of the presentinvention. The statements 2200 can be generated automatically based onstatement definitions. Such statements 2200 can be in draft mode untilall or substantially all data is complete. Any statement data thatcannot be automatically created can put the statement into a “pendingapproval” status or the like, and the administrator can manually enterany such statement data that could not be automatically created. Thestatement 2200 can provide the client with a suitable listing or invoiceof purchases requiring payment by the client, including a breakdown ofindividual purchases and purchase totals, and total amounts owed.

As discussed previously, the statements 2200 can be generated based onstatement definitions. FIG. 23 illustrates a statement definition reportpage 2300, in accordance with an exemplary embodiment of the presentinvention. The statement definition report page 2300 can be accessed byselecting, for example, the statement tab 2305 in the sub-menu 1615under the “Reports” tab 1610 in the top-level menu 730. Statementdefinitions can be set up based on the rules specified in, for example,the contract or other binding agreement with the card processor 110. Thestatement (e.g., statement 2200) can be created on the appropriate dayand/or time based on the schedule established in the contract. Themanagement application server module 125 can be configured to limit thechanges that can occur to a definition once a statement has been created(e.g., through appropriate rules, restrictions and security features).In addition, the management application server module 125 is configuredto allow the administrator to manually add one-time entries to astatement. The statement definition report page 2300 can include anysuitable information for generating statements, such as, for example,client details (e.g., client addresses 2310), statement definitiondetails 2315, line item group details 2320, line item definition details2325, line item parameter details 2330 and other like information.

The management application server module 125 is also configured toprovide extensive exception reporting tools. FIG. 24 illustrates anexception report page 2400, in accordance with an exemplary embodimentof the present invention. The exception report page 2400 can be accessedby selecting, for example, the exception tab 2405 in the sub-menu 1615under the “Reports” tab 1610 of the top-level menu 730. According to anexemplary embodiment, on a periodic basis, card-product-level exceptionscan be reported using appropriate screening filters (e.g., based onpre-defined rules or other suitable filtering or screening parameters).Examples of such available exception reports include, for example:“Generate Exceptions” (e.g., flag exceptions to generate for a givendate); “Exception Summary” (e.g., a summary of any or all exceptions bycard or account number); “Card Balance Changing Sign” (e.g., debit cardsand the like that had a negative balance, and that have now gonepositive, and vice versa for credit cards and the like); “CreditBalances”; “Excessive Authorizations” (e.g., card products with anexcessive number of authorizations per day); “Excessive Fees” (e.g.,card products with excessive fees per day); “Excessive Returns” (e.g.,card products with excessive returns per day); “Foreign Transactions”(e.g., card products with foreign transactions); “High DollarTransactions” (e.g., card products with high dollar transactions perday); “High Risk MCC” (e.g., card products flagged with high risk MCCtransactions); “High Value Loads” (e.g., card products flagged with highvalue load transactions; “Negative Balances”; “Negative Balances (30Days)”; “Negative Balances (60 Days)”; “Negative Balances (90 Days)”“Out of Balance”; “Velocity Checks”; and any other suitable exceptionreports. By selecting any one of these entries, the administrator canview the details of the chosen exception report.

For example, FIGS. 25A and 25B illustrate exception detail report pages,in accordance with an exemplary embodiment of the present invention. Asillustrated in FIG. 25A, high risk MCC summary page 2505 can list asummary of cards flagged with high risk MCC transactions by program,including such items as the program name, BIN, number of accounts, anddollar amounts of transaction not reviewed, reviewed and alerted, aswell as other suitable summary information. As illustrated in FIG. 25B,high risk MCC detail page 2510 can present a display of the details ofcard products with high risk MCC transactions for the day by program,including items similar to or different than those listed in the highrisk MCC summary page 2505. The exceptions can be built from the dailyor periodic transaction detail that can be provided in the reports(e.g., general report 200, posted report 300 and authorization report400 or any other suitable report(s)) received from the card processors110. The exceptions can be marked as, for example, not-reviewed,reviewed or alerted, as illustrated in the exemplary exception detailreport pages of FIGS. 25A and 25B. An exception history can bemaintained (e.g., in database module 120) for research and reportingpurposes. As with other reporting pages, the administrator can filterthe information displayed on the exception reporting pages by enteringappropriate report criteria in the respective report filter criteriasections (e.g., section 2515 of the high risk MCC summary page 2505and/or section 2520 of the high risk MCC detail page 2510) to view anysuitable additional or alternative subset of the detailed exceptioninformation.

The management application server module 125 can provide theadministrator or other appropriate user with any other suitablefinancial report based on information associated with the card products.For example, FIG. 26 illustrates a financial reports page 2600, inaccordance with an exemplary embodiment of the present invention. Thefinancial reports page 2600 can be reached by selecting, for example,the “Financial” tab 2005 in the sub-menu 1615 under the “Reports” tab1610 of the top-level menu 730. As illustrated in FIG. 26, the financialreports can be grouped as, for example, portfolio based reports 2605,DDA reports 2610, GL reports 2615 and card-based reports 2620. Examplesof available financial reports include, for example: “Daily Balances”(e.g., daily balances by program); “Daily Bank Account Balances DDA”;“Daily Bank Account Balances GL (Confidential)”; “Daily Bank AccountReconciliations”; “Unposted Transactions” (e.g., daily findingaccounts/unposted transactions); “Settlement Report” (e.g., settlementaccount funds); “Portfolio Overview” (e.g., current portfoliooverview/card summary); “0/30+ Days Negative Balances”; “Daily FundsMovement” (e.g., daily finds movement by program with card productaggregate); “MIS” (e.g., MIS data for a given date range); “StateFrequency” (e.g., number of cards by state/program type); “MissingNon-Financial” (e.g., transactions without non-financial information);“Lost/Stolen (Last 7 Days)” (e.g., cards flagged as lost/stolen withinthe last seven days); “Card Transaction Detail” (e.g., card details andauthorization/posted history); “Gift Card Program Summary”; “Gift CardACH Funding” (e.g., daily card product funding); “ACH File Log” (e.g.,client ACH files/audit trail); “ACH Queue” (ACH requests/queue); and anyother suitable financial reports. By selecting any one of these entriesunder the appropriate report group, the administrator can view thedetails of the chosen financial report. Any or all of the financialreports can have date range and other report-specific filters so thatthe data can be generated at a point in time in many different views. Togenerate such financial reports, the database (e.g., database module120) can be built from the daily or periodic report files (e.g., generalreport 200, posted report 300 and authorization report 400) from thecard processors 110. Any suitable types, ordering, grouping and otherlike characteristics of the financial reports can be displayed andavailable to a user through the financial reports page 2600.

FIGS. 27A and 27B illustrate financial report pages, in accordance withan exemplary embodiment of the present invention. As illustrated in FIG.27A, unposted summary page 2705 can list the daily funding accounts andunposted transactions. For example, the management application servermodule 125 can take the aggregate card balance minus value loads, andsubtract the spending and cardholders fees for the previous two or fourdays (or any suitable time frame) to generate a calculated balance,which should be less than the funding account balance also listed in theunposted summary page 2705. As illustrated in FIG. 27B, settlementsummary page 2710 can display settlement account funds. For example, themanagement application server module 125 can take the settlement accountbalance for the selected time period (e.g., day) and add in thesettlement paid out for the previous two days to generate an adjustedbalance. As with other displayed pages, the administrator can filter theinformation displayed on the financial reporting pages by enteringappropriate report criteria in the respective report filter criteriasections (e.g., section 2715 of the unposted summary page 2705 and/orsection 2720 of the settlement summary page 2710) to view any suitableadditional or alternative subset of the detailed financial information.

The management application server module 125 can display any othersuitable reports or information through the associated GUI. As discussedpreviously, the client application server module 115 can be configuredto allocate and assign card numbers corresponding to each BIN (or otherunique identifier) for the card products. According to exemplaryembodiments, the system 100 can be configured to display a summary(e.g., a distribution summary) of card numbers for each BIN through aGUI, such as the GUI used for the management application server module125. For example, FIG. 28 illustrates a card number summary page 2800,in accordance with an exemplary embodiment of the present invention. Thecard number summary page 2800 can be reached by selecting, for example,the “Gift Card” (or suitable “Card product”) tab 1620 in the sub-menu1615 under the “Reports” tab 1610 in the top-level menu 730. Forexample, the card number summary page 2800 can display the count of“Available” card number per BIN (e.g., where, merely for purposes ofillustration, the last six digits of each of the numbers listed in the“Card Status” row can comprise a BIN or other unique identifier). Othersuitable card number summary information can be displayed to the user inthe card number summary page 2800, including, for example, the count of“Shipped,” “Activated,” “Activated & Loaded” and “Destroyed” cardsand/or card numbers per BIN and other like information. In addition, thesystem 100 can be configured to display a list of available card numbersfor each BIN through the GUI to manage the card products across cardprocessors 110, although such a feature can be disabled by the system100 for purposes of security when appropriate.

Although the card product management system 100 can be used to manageinformation associated with cards and card products, the system 100 canbe used to manage financial information and conduct suitable types offinancial transactions, such as, for example, money transmittals ortransfers and the like, either with or without the use of anaccompanying card product. For example, a local user can request that alocal financial institution (e.g., a bank) transfer or otherwisetransmit a sum of money to an individual in a remote location (e.g.,another bank or outlet in another country) using the system 100. Thelocal financial institution can access the system 100 to perform themonetary transfer (e.g., transfer the money from one user account toanother, from one card processor 110 to another, from one financialinstitution to another, or other like transaction). The individual inthe remote location can then go to the remote bank that received themonetary transfer, and present appropriate identification to the remotebank. The identity of the individual can be verified by the remote bankusing the system 100 (e.g., the name, address and, for example, apersonal identification number (PIN) can correspond to recordsmaintained in the system 100 for the money transmittal). Once verified,the individual can be given the transferred money. The card productmanagement system 100 can be used for other such financial transactions,such as, for example, “pay pass” accounts, biometric accounts and thelike, either with or without the use of a card or card product.

The card product management system 100 is configured to be compliantwith all applicable federal and state laws and regulations, includingstate laws restricting fees and expiration dates, state disclosure laws,state laws requiring small balance refunds at the point of sale, statemoney transmitter licensing laws, state abandoned property laws, and thelike.

Each of modules of card product management system 100, including agentportal module 105, client application server module 115, managementapplication server module 125, and graphical user interface module 130,or any combination thereof, can be comprised of any suitable type ofelectrical or electronic component or device that is capable ofperforming the functions associated with the respective element.According to such an exemplary embodiment, each component or device canbe in communication with another component or device using anyappropriate type of electrical connection that is capable of carryingelectrical information. Alternatively, each of the modules of cardproduct management system 100 can be comprised of any combination ofhardware, firmware and software that is capable of performing thefunctions associated with the respective module.

Alternatively, the card product management system 100 can be comprisedof one or more microprocessors and associated memory(ies) that store thesteps of a computer program to perform the functions of the modules ofthe system 100. The microprocessor can be any suitable type ofprocessor, such as, for example, any type of general purposemicroprocessor or microcontroller, a digital signal processing (DSP)processor, an application-specific integrated circuit (ASIC), aprogrammable read-only memory (PROM), an erasable programmable read-onlymemory (EPROM), an electrically-erasable programmable read-only memory(EEPROM), a computer-readable medium, or the like. The memory can be anysuitable type of computer memory or any other type of electronic storagemedium, such as, for example, read-only memory (ROM), random accessmemory (RAM), cache memory, compact disc read-only memory (CDROM),electro-optical memory, magneto-optical memory, or the like. As will beappreciated based on the foregoing description, the memory can beprogrammed using conventional techniques known to those having ordinaryskill in the art of computer programming. For example, the actual sourcecode or object code of the computer program can be stored in the memory.For example, according to an exemplary embodiment, the agent portalmodule 105 and the management application server module 125 can each beimplemented using a WINDOWS™ server (e.g., WINDOWS™ 2003 or XP server)running on a suitable-equipped PC, or other similar computerarchitecture or computer systems (e.g., HEWLETT-PACKARD™ servers).According to an exemplary embodiment, the database module 120 can beimplemented using a SQL server and corresponding SQL database.

The card product management system 100 can include other suitablemodules and components (whether implemented in hardware, software,firmware or any combination thereof) for use in managing the system 100,including log modules, error modules, security modules, and the like.For example, the system 100 can include a suitable first firewall 150located between the card processors 110 and the agent portal module 105to prevent any malicious intrusion into or computer attacks on thesystem 100. A suitable second firewall 155 can be located between theagent portal module 105 and the combination of the database module 120and management application server module 125 to prevent unrestricteduser access to the management application server module 125 and to theinformation stored and maintained in the storage module 120.

FIG. 29 is a flowchart illustrating steps for managing card productinformation, in accordance with an exemplary embodiment of the presentinvention. Each of a plurality of card processors are interfaced to instep 2905. In step 2910, one of the plurality of card processors isselected in accordance with a unique identifier associated with a cardproduct to process information associated with the card product. In step2915, information associated with card products is managed for theplurality of card processors. In step 2920, messages for communicationto a respective card processor are transformed into a format utilized bythe respective card processor. In step 2925, information associated withcard products is received from each of the card processors. According toan exemplary embodiment, the information from each card processorcomprises a plurality of reports. For example, the plurality of reportscan include at least one of a general report, a posted report and anauthorization report. In step 2930, the information from each of thecard processors is normalized to transform the information into auniform format. In step 2935, the transformed information is validatedto ensure accuracy of the information. In step 2940, reports can begenerated for information associated with the card products. Forexample, each report can be populated with information in accordancewith an identification of a user.

In addition, according to exemplary embodiments, information associatedwith card products can be stored. Users can be provided access to manageinformation associated with card products. For example, a graphical userinterface can be displayed through which users access informationassociated with card products. According to an exemplary embodiment,access can be granted to a user through the graphical user interfaceusing a password and an associated computer network address of the user.Once granted access, products can be presented or otherwise displayed toa user through the graphical user interface in accordance with at leastone of a user identification and an association with a financialinstitution. For example, a theme of the graphical user interface can beassociated with each card processor. Each card processor can bepresented with the theme associated with the card processor wheninteracting through the graphical user interface.

According to an exemplary embodiment of the present invention, the cardprocessors are configured to associate corresponding BINs to the cardproducts. Card numbers can be allocated corresponding to each BIN forthe card products. A summary of card numbers for each BIN can bedisplayed. Each card product can comprise a card product number. Thecard product number can comprise a first portion of digits and a secondportion of digits. The first portion of digits comprises a BIN. The cardprocessors are configured to associate BINs to the card products. Cardnumbers can then be allocated to substantially all of the second portionof digits for each BIN.

FIG. 30 is a flowchart illustrating steps for detecting tampering withinformation communicated to a card processor, in accordance with anexemplary embodiment of the present invention. Messages to the cardprocessors can include a query comprising a computer network address ofa file or the like. In step 3005, the computer network address can beencrypted. For example, a cryptographic hash function or other likeencryption technique can be used to encrypt the computer networkaddress. In step 3010, the encrypted computer network address can beappended to an end of the query. In step 3015, tampering with thecomputer network address can be detected by comparing the computernetwork address and a decryption of the encrypted computer networkaddress. Alternatively, in step 3020, tampering with the computernetwork address can be detected by comparing the encrypted computernetwork address and a re-encryption of the computer network address.

FIG. 31 is a flowchart illustrating steps for processing card products,in accordance with an exemplary embodiment of the present invention. Instep 3105, a BIN can be associated to each of a plurality of cardproducts by a card processor. Each card product can comprise a cardproduct number. The card product number can comprise a first portion ofdigits and a second portion of digits. The first portion of digits cancomprise the BIN. In step 3110, values can be assigned to substantiallyall of the second portion of digits of each card product by anon-processor. The non-processor is configured to manage informationassociated with the plurality of card products. The values assigned tosubstantially all of the second portion of digits of each card productcan comprise a card number. Card numbers can be allocated for each BINby the non-processor. For example, card numbers can be allocatedsequentially for each BIN. Alternatively, card numbers can be allocatedrandomly for each BIN. The values assigned to substantially all of thesecond portion of digits of each card product can correspond to separateusers.

Any or all of the steps of a computer program as illustrated in FIGS.29-31 can be embodied in any computer-readable medium for use by or inconnection with an instruction execution system, apparatus, or device,such as a computer-based system, processor-containing system, or othersystem that can fetch the instructions from the instruction executionsystem, apparatus, or device and execute the instructions. As usedherein, a “computer-readable medium” can be any means that can contain,store, communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer readable medium can be, for example but not limited to, anelectronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system, apparatus, device, or propagation medium. Morespecific examples (a non-exhaustive list) of the computer-readablemedium can include the following: an electrical connection having one ormore wires, a portable computer diskette, a random access memory (RAM),a read-only memory (ROM), an erasable programmable read-only memory(EPROM or Flash memory), an optical fiber, and a portable compact discread-only memory (CDROM).

Exemplary embodiments of the present invention can be used inconjunction with any device, system, process or transaction thatprocesses card product information. Exemplary embodiments can be used byfinancial institutions as part of reloadable or non-reloadable cardproduct programs to access, administer and manage the informationassociated with the card products or to perform other suitable types offinancial transactions, either with or without the use of the associatedcard products.

It will be appreciated by those of ordinary skill in the art that thepresent invention can be embodied in various specific forms withoutdeparting from the spirit or essential characteristics thereof. Thepresently disclosed embodiments are considered in all respects to beillustrative and not restrictive. The scope of the invention isindicated by the appended claims, rather than the foregoing description,and all changes that come within the meaning and range of equivalencethereof are intended to be embraced.

All United States patents and applications, foreign patents, andpublications discussed above are hereby incorporated herein by referencein their entireties.

1. An information management system, comprising: a computer server,wherein the computer server includes an interface module; and aplurality of card processors in communication with the computer servervia the interface module, wherein the computer server is configured tointerface with each of the plurality of card processors via theinterface module, and wherein the computer server is configured tochoose one of the plurality of card processors in accordance with aunique identifier associated with a card product to process informationassociated with the card product.
 2. The information management systemof claim 1, wherein the interface module is configured to transformmessages for communication to a respective card processor into a formatutilized by the respective card processor.
 3. The information managementsystem of claim 1, comprising: a database in communication with thecomputer server, wherein the database module is configured to storeinformation associated with card products.
 4. The information managementsystem of claim 3, comprising: a management module in communication withthe database, wherein the management module is configured to manage theinformation management system.
 5. The information management system ofclaim 1, wherein each card product comprises a card number, wherein thecard number comprises a first portion of digits and a second portion ofdigits, wherein the first portion of digits comprises a bankidentification number (BIN), wherein the card processors are configuredto associate BINs to the card products, and wherein the computer serveris configured to allocate card numbers to substantially all of thesecond portion of digits for each BIN.
 6. A card product managementsystem, comprising: an agent portal module; and a plurality of cardprocessors in communication with the agent portal module, wherein theagent portal module is configured to interface with each of theplurality of card processors, and wherein the agent portal module isconfigured to choose one of the plurality of card processors inaccordance with a unique identifier associated with a card product toprocess information associated with the card product.
 7. The cardproduct management system of claim 6, wherein the agent portal modulecomprises: a client application server module.
 8. The card productmanagement system of claim 7, wherein the client application servermodule is configured to transform messages for communication to arespective card processor into a format utilized by the respective cardprocessor.
 9. The card product management system of claim 8, whereinmessages to the card processors include a query comprising a computernetwork address of a file, and wherein an encryption of the computernetwork address is appended to an end of the query.
 10. The card productmanagement system of claim 9, wherein the client application servermodule is configured to detect tampering with the computer networkaddress by comparing the computer network address and a decryption ofthe encrypted computer network address.
 11. The card product managementsystem of claim 9, wherein the client application server module isconfigured to detect tampering with the computer network address bycomparing the encrypted computer network address and a re-encryption ofthe computer network address.
 12. The card product management system ofclaim 11, wherein the encryption of the computer network addresscomprises a cryptographic hash function.
 13. The card product managementsystem of claim 7, wherein the client application server module isconfigured to receive information associated with card products fromeach of the card processors, and wherein the information from each ofthe card processors is normalized to transform the information into auniform format utilized by the agent portal module.
 14. The card productmanagement system of claim 13, wherein the information from each cardprocessor comprises a plurality of reports.
 15. The card productmanagement system of claim 14, wherein the plurality of reportscomprises at least one of a general report, a posted report and anauthorization report.
 16. The card product management system of claim13, wherein the transformed information is validated to ensure accuracyof the information.
 17. The card product management system of claim 7,wherein the client application server module is configured to generatereports for information associated with card products.
 18. The cardproduct management system of claim 17, wherein each report is populatedwith information in accordance with an identification of a user.
 19. Thecard product management system of claim 7, comprising: a database modulein communication with the client application server module, wherein thedatabase module is configured to store information associated with cardproducts.
 20. The card product management system of claim 19,comprising: a management application server module in communication withthe database module, wherein the management application server module isconfigured to manage the card product management system.
 21. The cardproduct management system of claim 19, wherein the agent portal moduleis configured to allow access by users to manage information associatedwith the card products.
 22. The card product management system of claim19, wherein the agent portal module comprises: a graphical userinterface module, wherein the graphical user interface module isconfigured to display a graphical user interface through which usersinteract with the card product management system.
 23. The card productmanagement system of claim 22, wherein a user is granted access to thecard product management system through the graphical user interfaceusing a password and an associated computer network address of the user.24. The card product management system of claim 22, wherein products arepresented to a user through the graphical user interface in accordancewith at least one of a user identification and an association with afinancial institution.
 25. The card product management system of claim22, wherein a theme of the graphical user interface is associated witheach card processor, and wherein each card processor is presented withthe theme associated with the card processor when interacting with thecard product management system through the graphical user interface. 26.The card product management system of claim 6, wherein the cardprocessors are configured to associate corresponding bank identificationnumbers (BINs) to the card products, and wherein the agent portal moduleis configured to allocate card numbers corresponding to each BIN for thecard products.
 27. The card product management system of claim 6,wherein the agent portal module is configured to display a summary ofcard numbers for each BIN through a graphical user interface.
 28. Thecard product management system of claim 6, wherein the unique identifiercomprises a bank identification number (BIN).
 29. The card productmanagement system of claim 6, wherein each card product comprises a cardproduct number, wherein the card product number comprises a firstportion of digits and a second portion of digits, wherein the firstportion of digits comprises a bank identification number (BIN), whereinthe card processors are configured to associate BINs to the cardproducts, and wherein the agent portal module is configured to allocatecard numbers to substantially all of the second portion of digits foreach BIN.
 30. The card product management system of claim 6, wherein thecard product comprises a gift card.
 31. The card product managementsystem of claim 6, wherein the card product comprises at least one of adebit card, a health savings account (HSA) card, a flexible spendingaccount (FSA) card, and a reloadable payroll card.
 32. A method ofmanaging card product information, comprising the steps of: a.)interfacing with each of a plurality of card processors; and b.)selecting one of the plurality of card processors in accordance with aunique identifier associated with a card product to process informationassociated with the card product.
 33. The method of claim 32, whereinthe card processors are configured to associate corresponding bankidentification numbers (BINS) to the card products, and wherein themethod comprises the step of: c.) allocating card numbers correspondingto each BIN for the card products.
 34. The method of claim 32, whereineach card product comprises a card product number, wherein the cardproduct number comprises a first portion of digits and a second portionof digits, wherein the first portion of digits comprises a bankidentification number (BIN), wherein the card processors are configuredto associate BINs to the card products, and wherein the method comprisesthe step of: c.) allocating card numbers to substantially all of thesecond portion of digits for each BIN.